Closed Bug 474732 Opened 13 years ago Closed 13 years ago

Rerunning configure causes the world to be rebuilt


(Firefox Build System :: General, defect)

Not set


(Not tracked)



(Reporter: roc, Assigned: kairo)



(Keywords: fixed1.9.1)


(2 files, 1 obsolete file)

Used to be that you could rerun 'configure' and then 'make all' would still be pretty good about doing a dep-build. But right now, if I rerun 'configure' then 'make' rebuilds the entire world. This is unfortunate.
Did anything in change? The world now depends on for correctness reasons, so any configure change (even fairly trivial ones) trigger world-rebuilds. This was by design, according to bug 463824.

If a reconfigure without any changes whatsoever causes a rebuild, that's definitely a bug.
No, I just tested it with "configure; make all; configure; make all".
Hmm, does configure always re-write and make trigger a rebuild if any file has a newer date? If so, that might explain our problem. Not sure how to solve it, though.
We have code for other files like mozilla-config.h, that writes to a temporary file and then only overwrites the real file with the temporary if they're different:

  # Only write mozilla-config.h when something changes (or it doesn't exist)
  if cmp -s $_CONFIG_TMP $_CONFIG_DEFS_H; then
    rm $_CONFIG_TMP
    AC_MSG_RESULT("creating $_CONFIG_DEFS_H")

    echo ==== $_CONFIG_DEFS_H =================================
    cat $_CONFIG_DEFS_H
roc, that sounds interesting, we probably might want to do this with as well - I had thought about some approach like that but didn't know we're already doing this for other stuff.
(In reply to comment #4)
> that writes to a temporary file and then only overwrites
> the real file with the temporary if they're different:

Sounds like the correct thing to do here, definitely.
Depends on: 463824
So, as we suspected, the problem is that gets recreated every time we run configure, and because we now have Makefile dependencies on everywhere which only look at the date/time of the file, we come to rebuild everything on every run of configure.

We're recreating two times actually:
1) always spits it out as a Makefile that needs updating, and so we handle that to config.status in $CONFIG_FILES every time. We can avoid that by treating like other Makefiles in
2) After running the NSPR configure, we recreate with the some new vars from nspr-config every time. We can avoid that by rewriting it to a temp file there and only move that to be the new if anything changed.

The attached patch includes the mentioned steps for avoiding recreation of, I could get the build time of SeaMonkey without any code changes down to 1 minute from over 15 minutes before that change.
If the patch is accepted, some or all of those changes also need to be copied to the SpiderMonkey build system, I guess. comm-central doesn't need an extra patch as it's reusing the same and NSPR is only configured by the Mozilla repo.
Assignee: nobody → kairo
Attachment #359612 - Flags: review?(ted.mielczarek)
Sorry, the analysis of the problem was correct but my first approach omitted that fact that actually needs to be recreated when its vars change. Because of that, we need to let config.status recreate it but force back the old version (with the old date/time) when nothing has changed. In the main Mozilla configure, we need to do that at the very end to take the NSPR replacing stuff into account, everywhere else we can just do it right after AC_OUTPUT().
Attachment #359612 - Attachment is obsolete: true
Attachment #359748 - Flags: review?(ted.mielczarek)
Attachment #359612 - Flags: review?(ted.mielczarek)
This is the same thing for comm-central - here we also can catch changes right after AC_OUTPUT().
Attachment #359750 - Flags: review?(bugzilla)
Comment on attachment 359750 [details] [diff] [review]
comm-central patch

r=me. This looks ok and seems to work fine - I've tried a couple of scenarios and it regenerated (or not) correctly.
Attachment #359750 - Flags: review?(bugzilla) → review+
Comment on attachment 359750 [details] [diff] [review]
comm-central patch

Pushed this comm-central part as
Comment on attachment 359748 [details] [diff] [review]
make recreation not force world rebuilds

Looks good, thanks for the patch!
Attachment #359748 - Flags: review?(ted.mielczarek) → review+
Pushed on trunk as - waiting for green cycles with the patch before asking for a1.9.1
Closed: 13 years ago
Resolution: --- → FIXED
Attachment #359748 - Flags: approval1.9.1?
Comment on attachment 359748 [details] [diff] [review]
make recreation not force world rebuilds

1) We have builds on all platforms cycling green with this patch,
2) it is quite low-risk as we're doing similar stuff for other files already (cairo-features.h etc.),
3) it is potentially high-reward as it shortens build times when configure runs but isn't actually changed.

With those reasons, requesting 1.9.1 approval.
Attachment #359748 - Flags: approval1.9.1? → approval1.9.1+
Pushed to 1.9.1 as
Keywords: fixed1.9.1
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.2a1
MozillaBuild's cmp does not understand the -b option:

make[3]: Leaving directory `/e/builds/moz2_slave/mozilla-central-win32/build/obj-firefox/js/src'
cmp: invalid option -- b
cmp: Try `cmp --help' for more information.

I guess that's a debugging leftover, it should simply use -s (like the other places).
Sylvain, you're right in that it's a debugging leftover, it has been filed as bug 477001 and a patch is on there.
Depends on: 477001
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.