1369167 - make release builds check for specific versions of Rust/Cargo, not minimum versions

Status: RESOLVED WONTFIX

(Firefox Build System :: General, enhancement)

Description

[Nathan Froyd [:froydnj]]

We've had two bugs filed recently, bug 1360521 and bug 1368280, about issues building release versions of Firefox with newer Rust versions.  These Rust versions (specifically, Cargo) broke backwards compatibility and therefore couldn't be used to compile Firefox.  (The same problem exists for our C++ compilers, actually....)

While you could argue that people who are building release versions of Firefox should really Know What They Are Doing, there's also the argument that we should make it difficult to screw up building Firefox, no matter who is building it and when.  We already have one third party (Cliqz) doing various things with release Firefox and we may come to have more; we should make it easy for new partners to build Firefox and not have to learn sekret incantations every time.

Locking release Firefox to a specific version (or maybe range of versions) would serve this purpose.  Open to hearing about others.

Comment 1

[(not currently active) Ted Mielczarek]

This seems like it's gonna be a pain given the rapid release cycle of the Rust project, and the incentives to keep your local toolchain updated to stable. Specifically, I'm likely to `rustup update stable` frequently, only to find myself unable to build Firefox anymore.

We could mitigate this by doing two things:
1) Having `mach bootstrap` explicitly install the Rust toolchain version we want, like `rustup toolchain install 1.17.0`. That way it won't be just "stable" which can get updated to a newer version.
2) Have configure detect when rustc/cargo are actually rustup, and explicitly use the version we want. I'm not sure that there's a great way to do this. rustup does have `override`, so we could do `rustup override add <version>` in the objdir and presumably things would work OK.

Comment 2

[Mike Hommey [:glandium]]

I'm pretty much opposed to this. For one, the two bugs you link to, are actually one bug. That cargo had a backwards incompatible change is unfortunate, but it's also a rare event.

We don't put a cap on the version of clang and gcc we allow to build against. I don't see why we should do the same with rust/cargo.

Comment 3

[Ralph Giles (:rillian)]

I agree with Ted and Mike. I seems like this would just make more work for developers, especially when building older releases.  The only thing that makes sense were would be to gate on MOZ_AUTOMATION, which I don't think addresses the desired issue.

The minimum-supported rust version at least gives them a guide for what toolchain should work for a particular release, so there's guidance available.

Closing based on the above assessments.