Closed Bug 1478798 Opened Last year Closed Last year

Don't manage the CLOBBER file in tup builds as we do in make builds

Categories

(Firefox Build System :: General, enhancement)

enhancement
Not set

Tracking

(firefox63 fixed)

RESOLVED FIXED
mozilla63
Tracking Status
firefox63 --- fixed

People

(Reporter: chmanchester, Assigned: chmanchester)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Tup should be able to protect us from some major classes of clobber builds, so hopefully the CLOBBER file isn't going to be needed as often. When it is, we will probably have reason to find and fix the issue.

Today the machinery that runs configure in the Tup build will respect the CLOBBER file as it does in a make build. Maybe we can just detect when CLOBBER has been touched, run the build anyway, and if it fails print a special message asking the user to clobber and file a bug. This could be an annoyance if people end up waiting for a build that might fail due to a clobber bug, but hopefully this wouldn't be the norm!
Comment 0 isn't quite accurate. If the build driver detects that configure is out of date or hasn't been run, then the invocation to run configure will respect the CLOBBER file. However, an incremental build in tup that doesn't run configure will not respect the CLOBBER file, even if it's out of date.

This is almost what we want, because clobber reasons outside of Tup are the ones we know we'll still need to handle, except in these cases we'd probably want to just rm configure artifacts before re-running configure rather than rm'ing the entire objdir.
Looking through clobber messages from the last two years I found two more situations Tup can't prevent: references to stale paths in the virtualenv (bug 1371485), and state accumulated by test support files in the objdir (bug 1416332).

I have a patch that detects when we're going to re-run configure in the tup build, checks the clobber file before doing so and if a clobber would happen does a miniature auto clobber of intermediate configure artifacts, $objdir/_virtualenvs, and $objdir/_tests instead before proceeding. Getting rid of the virtualenv invalidates all our python, so the resulting build is a little slow, but it's a lot better than removing the entire objdir.
Assignee: nobody → cmanchester
Depends on: 1482516
Comment on attachment 8998008 [details]
Bug 1478798 - Handle the CLOBBER file optimistically in the Tup backend.

Michael Shal [:mshal] has approved the revision.
Attachment #8998008 - Flags: review+
Pushed by cmanchester@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/adadcbb4f742
Handle the CLOBBER file optimistically in the Tup backend. r=mshal
https://hg.mozilla.org/mozilla-central/rev/adadcbb4f742
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
You need to log in before you can comment on or make changes to this bug.