We can explicitly call `cargo +stable build` for geckolib, and have a min
version check in mach.

We'll only get the rust-toolchain file pinning for one of the two and will
have to build some mach stuff for the other, but it will be considerably
simpler than what we have right now.

I think we should do this; with geckolib having the
slightly-more-complicated build because it doesn't _require_ stable so
doing just "cargo build" will work as well.

On Nov 14, 2017 8:22 AM, "Jack Moffitt" <j...@metajack.im> wrote:

> I'm all for it, though I seem to recall there was some issue about
> needing two versions of Rust? How will we support the two different
> pinned versions (one for ./mach build and one for ./mach
> build-geckolib)?
>
> jack.
>
> On Tue, Nov 14, 2017 at 3:41 AM, Simon Sapin <simon.sa...@exyr.org> wrote:
> > In https://github.com/servo/servo/issues/11361 we’ve discussed using
> > rustup.rs to bootstrap Rust and Cargo.
> >
> > With https://github.com/servo/servo/pull/19213 landing soon, I think the
> > last blocker is resolved.
> >
> > One proposal has been to use rustup when available, and fall back to our
> > existing mechanism when not. However I think rustup is well-established
> > enough these days and I’d like to go further: make it a requirement and
> > remove our code that duplicates rustup’s functionality: downloading and
> > extracting tarballs, juggling toolchain versions, etc.
> >
> > mach would make sure to run cargo/rustc/etc. through rustup
> > (https://github.com/rust-lang-nursery/rustup.rs/issues/1293), and set
> the
> > $RUSTUP_TOOLCHAIN environment variable to select the appropriate
> toolchain
> > version. Recent versions of rustup now download missing toolchains
> > automatically.
> >
> > We’d document instructions for installing rustup in our README, and
> again an
> > error message when mach cannot find a `rustup` executable.
> >
> > The `system-rust = true` configuration would remain available and run
> plain
> > `cargo` or `rustc` like before.
> >
> > Thoughts?
> >
> > --
> > Simon Sapin
> > _______________________________________________
> > dev-servo mailing list
> > dev-servo@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-servo
> _______________________________________________
> dev-servo mailing list
> dev-servo@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Reply via email to