Closed
Bug 1033958
Opened 10 years ago
Closed 10 years ago
configure always runs when mozconfig changes $PATH
Categories
(Firefox Build System :: General, defect)
Firefox Build System
General
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla33
People
(Reporter: glandium, Assigned: glandium)
References
Details
Attachments
(1 file)
3.81 KB,
patch
|
gps
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Assignee | ||
Comment 1•10 years ago
|
||
Theoretically, there are cases than $PATH that can be affected, but it's just simpler to talk about $PATH only, as it's about the only real case where i expect that to happen (since it involves setting a make_extra variable which grows itself). There's one make -f client.mk that I left out because it invokes mach environment with a different objdir (the case when going through each MOZ_BUILD_PROJECTS). Note the awful workaround because of what make does with := $(shell). I have serious bloodlust for client.mk. Starting to use mach there is definitely the first serious injury, I can't wait to kill it for good.
Attachment #8450048 -
Flags: review?(gps)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → mh+mozilla
Status: NEW → ASSIGNED
Comment 2•10 years ago
|
||
Comment on attachment 8450048 [details] [diff] [review] Avoid running configure on every build when mozconfig changes $PATH Review of attachment 8450048 [details] [diff] [review]: ----------------------------------------------------------------- I think we are both ashamed our names are attached to this. I support your blood lust for client.mk. What do you think about causing it to abort if used outside of mach/automation?
Attachment #8450048 -
Flags: review?(gps) → review+
Assignee | ||
Comment 3•10 years ago
|
||
(In reply to Gregory Szorc [:gps] from comment #2) > I support your blood lust for client.mk. What do you think about causing it > to abort if used outside of mach/automation? I think we can reasonably make it piggyback on mach for people still using it directly, changing some of mach display options when doing so (not adding timestamps, not using -s). So people using client.mk can still use it, and get the same results.
Assignee | ||
Comment 4•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/c5ac0914b65c
Comment 5•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/c5ac0914b65c
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Comment 6•10 years ago
|
||
Backed out because of how many people reported build issues once this had landed. Some of that was in bug 1034594, but there were also issues building c-c that resulted in: mozbuild.base.ObjdirMismatchException: Objdir mismatch: c:\t1\hg\objdir-sm\mozilla != c:\t1\hg\comm-central\objdir-sm\mozilla and Neil reported that his ./configure "was doing something wrong when it's running my .mozconfig".
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 7•10 years ago
|
||
Oops, forgot to cite: remote: https://hg.mozilla.org/mozilla-central/rev/e268bb51e084
Comment 8•10 years ago
|
||
(In reply to Gijs Kruitbosch from comment #6) > and Neil reported that his ./configure "was doing something wrong when it's > running my .mozconfig". To be fair, this might have been bug 817197, but something started making .mozconfig run from the srcdir instead of the objdir as it has historically done.
Comment 9•10 years ago
|
||
(In reply to comment #8) > To be fair, this might have been bug 817197 Or bug 762358.
Comment 10•10 years ago
|
||
Please upload or link to a pastebin of your mozconfig. We have pretty good test coverage of mozconfig processing and we're able to detect "bad" patterns. If we know what you're doing, we can either make it work or ban it. Either way, we don't get nebulous backouts for unknown failures.
Flags: needinfo?(neil)
Comment 11•10 years ago
|
||
(In reply to Gregory Szorc from comment #10) > Either way, we don't get nebulous backouts for unknown failures. At no point did I claim that my problem was specifically caused by this bug. I was just unlucky to get build bustage at the same time as several other people. (In reply to Gregory Szorc from comment #10) > Please upload or link to a pastebin of your mozconfig. http://mozconfig.pastebin.mozilla.org/5518604
Flags: needinfo?(neil)
Assignee | ||
Comment 12•10 years ago
|
||
From irc scrollback: <NeilAway> Gijs: well, found my problem, looks like I had a local patch conflicting with glandium's changes <NeilAway> Gijs: actually it was conflicting with bug 817197, so not glandium's fault after all
Assignee | ||
Comment 13•10 years ago
|
||
Both RattyAway and NeilAway had problems building c-c, which don't use m-c's client.mk. Bug 1034594 seems very much unrelated to this. Backing out the backout. https://hg.mozilla.org/mozilla-central/rev/81691a55e60f
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 14•10 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #13) > Both RattyAway and NeilAway had problems building c-c, which don't use m-c's > client.mk. And to be more specific, if anything has broken c-c recently, it's bug 762358, not this one. There is one issue I did identify with c-c, and it's with using paths relative to @TOPSRCDIR@ in mozconfig, which is a tricky issue.
Comment 15•10 years ago
|
||
(In reply to Mike Hommey from comment #14) > And to be more specific, if anything has broken c-c recently, it's bug > 762358, not this one. There is one issue I did identify with c-c, and it's > with using paths relative to @TOPSRCDIR@ in mozconfig, which is a tricky > issue. Indeed, because this switched from using the standard mozconfig loader to mach, which inexplicably thinks that it should chdir to your srcdir before running mozconfig.
Assignee | ||
Comment 16•10 years ago
|
||
(In reply to neil@parkwaycc.co.uk from comment #15) > Indeed, because this switched from using the standard mozconfig loader to > mach, which inexplicably thinks that it should chdir to your srcdir before > running mozconfig. That's not the problem, as, in fact, that was already the case before (where would it start it from when you don't have an objdir, or when the objdir itself is defined in mozconfig) The problem is that thanks to the python virtualenv being in objdir/mozilla/, and there being a mozinfo.json file there, the mozconfig parser thinks topsrcdir is that of mozilla/ when configuring the c-c parts. Just don't define your objdir using @TOPSRCDIR@ for now.
Assignee | ||
Comment 17•10 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #16) > Just don't define your objdir using @TOPSRCDIR@ for now. Note that MOZ_OBJDIR=obj-foo works, instead of @TOPSRCDIR@/obj-foo. However ../obj-foo doesn't work.
Comment 18•10 years ago
|
||
(In reply to Mike Hommey from comment #16) > (In reply to comment #15) > > Indeed, because this switched from using the standard mozconfig loader to > > mach, which inexplicably thinks that it should chdir to your srcdir before > > running mozconfig. > > That's not the problem, as, in fact, that was already the case before (where > would it start it from when you don't have an objdir, or when the objdir > itself is defined in mozconfig) Neither of these cases apply to me.
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•