1752835 - System clang used instead of downloaded clang when config/milestone.txt is changed

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Julien Wajsberg [:julienw]]

STR:

1. Change config/milestone.txt to a stable version, eg 99.0 (I haven't tried with others)
2. Run ./mach build

On my Debian Linux, I get errors such as bug 1747150 and bug 1747145, which are hints that the build system uses my system's clang instead of the downloaded clang stored in mozbuild.
Indeed ps aux | grep clang shows that /usr/bin/clang is used, whereas without the change I get things like /home/julien/.mozbuild/clang/bin/clang++.

I'd like to note that I can build just fine when I don't change config/milestone.txt.

Comment 1

[Mitchell Hentges [:mhentges] 🦀]

We only automatically bootstrap if building nightly (and you're using a VCS).
If you're changing the milestone, try creating/editing your mozconfig file and adding:

ac_add_options --enable-bootstrap

Does that resolve the issue for you?

Comment 2

[Julien Wajsberg [:julienw]]

But my bootstrap is already set up, why doesn't it use it?

(keeping the NI as I couldn't try the suggestion yet)

Comment 3

[Mitchell Hentges [:mhentges] 🦀]

Your bootstrap is indeed already set up, but we generally only use bootstrapped tools for a "developer context".
Non-developer contexts (such as Ubuntu/Fedora/etc package-building) want to use their own system's tooling/packages to fulfill Firefox' dependencies.

Our way of detecting whether we're building in a "developer context" or not is decided in part by whether you're building nightly or not :)

Comment 4

[Julien Wajsberg [:julienw]]

Non-developer contexts (such as Ubuntu/Fedora/etc package-building) want to use their own system's tooling/packages to fulfill Firefox' dependencies.

I would argue that I'm in a developer context (doing release simulations to test my patch), and that the assumption is a bit fragile :-)

I believe we (at mozilla) should generally ensure that our software is built with the version of clang that we know is working, even for non-developer contexts, and we should make --enable-bootstrap the default generally. Then package builders could use --disable-bootstrap explicitely, at their own risk. I think explicit is better than implicit in this case, and would lead to less surprises (such as the one I got here).

(In reply to Mitchell Hentges [:mhentges] 🦀 from comment #1)

If you're changing the milestone, try creating/editing your mozconfig file and adding:

ac_add_options --enable-bootstrap

Does that resolve the issue for you?

yes, this works for me, thanks!

Comment 5

[Mitchell Hentges [:mhentges] 🦀]

I don't necessarily disagree, but (conveniently) the build team had a discussion about our options here last night.
The use cases we need to support:

• Developers building on central: use bootstrapping
• Developers building a specific release (you are here 😉): use bootstrapping
• Firefox CI doing releases: use "bootstrapping" (implemented as "fetches" in CI, but it's the same idea)
• Downstream packagers of Firefox: use system tools
• Developers building a specific release to release as part of their distro (rare, but does happen): use system tools

Options:

• [glandium] Assume "should bootstrap" if a VCS is involved - this is pretty implicit and a weak connection though, IMO
• [glandium] Assume "should bootstrap" if ./mach is used instead of ./configure && make - however, this restricts our ability to move to different "build backends"
• [mitch] Assume "should use bootstrapped tools" if ~/.mozbuild is populated (so, if someone had manually run ./mach bootstrap)
  • [glandium] this forces the developer doing distro release builds to specify --disable-bootstrap
    • [mitch] I think that's an OK tradeoff?
• [glandium] Make ./mach bootstrap automatically create/update mozconfig to add --enable-bootstrap, [remove bootstrap inference]?
  • [mitch] This is blocked on mozconfig becoming declarative rather than an interpreted shell script, which isn't happening anytime soon

---

We can kick this can around the road, but there isn't a silver bullet - I most strongly lean towards implicitly using bootstrapped tools if they already exist, but there wasn't consensus within the team.
However, we did all agree that, since there's not an ideal solution here, it's not worth spending effort doing a refactor that will only shift the "burden of manually writing a mozconfig" elsewhere in the developer userbase.

---

I'm going to mark this as WONTFIX, but the bug that prompted the discussion and will host further "🤔" is over here