Closed Bug 1033958 Opened 6 years ago Closed 6 years ago

configure always runs when mozconfig changes $PATH

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla33

People

(Reporter: glandium, Assigned: glandium)

References

Details

Attachments

(1 file)

No description provided.
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: nobody → mh+mozilla
Status: NEW → ASSIGNED
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+
(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.
https://hg.mozilla.org/mozilla-central/rev/c5ac0914b65c
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Depends on: 1034594
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 → ---
(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.
(In reply to comment #8)
> To be fair, this might have been bug 817197

Or bug 762358.
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)
(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)
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
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: 6 years ago6 years ago
Resolution: --- → FIXED
(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.
(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.
(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.
(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.
(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.
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.