Closed Bug 715048 Opened 8 years ago Closed 8 years ago
.mk is generated into $topsrcdir instead of the $objdir
I discovered that if you have two objdirs for a single tree, and you build them alternately, configure is re-run every time even if you haven't changed anything. E.g. if your tree is at $TREE, and you have objdirs $TREE/debug64 and $TREE/opt64, you'll see this if you build debug64, then opt64, then debug64, etc. I captured the output of -d, I'm pretty sure these are the key lines: ... Finished prerequisites of target file `/home/njn/moz/mi4/d64/config.status'. ... Prerequisite `/home/njn/moz/mi4/.mozconfig.mk' is newer than target `/home/njn/moz/mi4/d64/config.status'. ... Must remake target `/home/njn/moz/mi4/d64/config.status'. ... Must remake target `configure-files'. ... Must remake target `configure'. The problem seems to be that .mozconfig.mk is not generated into the objdir. Presumably it should be. $(topsrcdir)/.mozconfig.mk appears in a couple of makefiles, as does $(topsrcdir)/.mozconfig.out.
This is the way it's supposed to work. .mozconfig.mk contains options that are used by client.mk, including things like *the name of the objdir*, so it has to be somewhere that can be included without an objdir present. I'm not sure why we force rebuilds when the .mk changes, though. There aren't all that many options you can reasonably set for client.mk. It's primarily used to set MOZ_OBJDIR and MOZ_MAKE_FLAGS nowadays.
This patch avoids re-running configure when .mozconfig.mk changes. Does anything else need to change? It'd probably be worth adding a comment to explain why .mozconfig.mk isn't in CONFIG_STATUS_DEPS.
Attachment #585893 - Flags: review?(ted.mielczarek)
Comment on attachment 585893 [details] [diff] [review] patch I don't think we need comments here. It's kind of nonsensical for the make options to be in the configure deps to begin with.
Attachment #585893 - Flags: review?(ted.mielczarek) → review+
I guess there's a race here -- if you trigger two builds at the same time there's a small chance that a .mozconfig.mk might be overwritten by the second build before it's read by the first build. But that has always been there, and this patch doesn't change it.
(In reply to Nicholas Nethercote [:njn] from comment #4) > I guess there's a race here -- if you trigger two builds at the same time > there's a small chance that a .mozconfig.mk might be overwritten by the > second build before it's read by the first build. But that has always been > there, and this patch doesn't change it. we could bake in a rando-hash type thing for the race-condition case, if we feel its worth it auto add to the generated .mk "MOZ_MAKE_SANITY=foobarRandomHash" and pass MOZ_MAKE_SANITY_CHECK=foobarRandomHash on the next launch of client.mk when recursed, or simply check it later if not :-) But I agree "not this bug"
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
Is this relevant for comm-central too?
(In reply to :aceman from comment #8) > Is this relevant for comm-central too? I think so. http://hg.mozilla.org/comm-central/file/a038320a5ee6/client.mk#l295 has .mozconfig.mk in CONFIG_STATUS_DEPS.
Guys, this patch causes a regression in build system. I reported it for thunderbird as Bug 731985 but it applies to Firefox too now (with this patch). Reproduction steps: 1) download mozilla tree, set up .mozconfig 2) build firefox (make -f client.mk build) 3) build fails or does not fail, it does not matter here 4) change .mozconfig (tweak build config etc.) 5) run "make -f client.mk build" - the changes in .mozconfig are ignored.
You need to log in before you can comment on or make changes to this bug.