Use rustup to get nightly rust

[mrmiywj]

Since every time build servo will use nightly rust compiler, is it a good idea to use rustup and overload servo path to build servo with nightly rustc? I mean, since there is a rust version manager, why not just use it?

[metajack]

Right now the UX for a developer is they can install a few dependencies, and than ./mach build and it just works. This would add a dependency that is not in any package manager, making your first build slightly more difficult.

Additionally we currently support having cargo and rust versions that are separate, but I'm not sure if that is a property we have ever relied on.

Previously, we sometimes had custom Rust builds, but this behavior has not been needed in quite some time.

We could add the overload file even if we don't make that the default way to manage Rust. Will rustup automatically download the right toolchain if it sees an overload file and that version isn't already downloaded? If so, that would enable cargo to work without mach, which would be a nice improvement.

So I think we would accept a PR to add an overload file. I think the discussion of whether we should outsource handling of the Rust toolchain to rustup should probably be discussed on dev-servo first to get more input.

[larsbergstrom]

IIRC @brson thought that we could eventually switch to using his rustup tool, but he's out for the rest of May, so we should probably sync up with him when he's back at work.

[mrmiywj]

Hmm, could I participate in this work, since it maybe look like a medium level work for servo?
Do I need to track the IRC online communication?

[metajack]

@mrmiywj Sure, sounds good.

I investigated how this could work. Overrides appear to be stored in ~/.multirust/overrides. So we can't just check one into the tree as I suggested before, unless rustup searches up the three until it finds .multirust like Cargo does.

An alternative implementation is to detect the presence of rustup on the system, and use that instead of our custom download logic. So this would mean we test for rustup and if present we use rust-nightly-date to set the toolchain override , and change our cargo and rust invocations to use the one in the PATH. I think as part of this work we should remove cargo-nightly-build and just use a single toolchain version.

The end result would be that if you have rustup installed, we would use that infrastructure to manage the toolchains and as a side benefit, raw cargo and rustc invocations would now work without having to go through mach.

There will need to be some care around cross compiling, assuming rustup can manage cross compile toolchains as well.

@larsbergstrom Does this strategy sound reasonable? Are we likely to need independent cargo and rust toolchains anymore?

[brson]

As you've seen there's no way yet to declare in a project what override rustup should use. If you want to integrate with rustup now it's probably best to do as jack describes and detect the existence of the rustup command, though that will leave you with two code paths for downloading the toolchain.

Another option might be to detect whether rustup exists, and if it doesn't install rustup to a private folder by overriding CARGO_HOME and RUSTUP_HOME. That way you would always be using rustup to manage the toolchain. You would still have two code paths though, so it's just complicated in a different way.

[paulrouget]

Now that rust-lang/rustup#460 has landed, can we reconsider this issue?

[paulrouget]

@metajack what do you think?

[jdm]

As long as we can get the -alt builds via rustup, this seems like it would be a useful improvement. I'm not sure how it will handle a nightly override for Servo as well as a stable override for Stylo, however.

[metajack]

I guess one way would be to let rustup manage servo and mach manage stylo. Or put a rust-toolchain config in the libgecko dir?

[shinglyu]

(@paulrouget asked me to help with this)

So just to make sure, the current plan is to

• Add a override file in servo directory
• Detect if rustup is present in the current system
  • Yes => use rustup + override file to download rustc and cargo and use them
  • No => use the old mach download mechanism (?)
• For stylo, keep the mach behavior until we agree to switch to rustup (?)

[shinglyu]

^ @metajack ?

[metajack]

That sounds fine to start. I would eventually like to end up with just the rustup bootstrapping, but we need some clever way to deal with stylo.

The ideal end goal is that if someone does cargo build instead of ./mach build it would just work aside from the weird cases like Android. In other words, we'd need no bootstrapping for basic build and run.

[shinglyu]

Sounds good, I'll start working on this.

[shinglyu]

Should we still keep the system-rust and system-cargo option? They seem redundant to me if we choose rustup by default?

[metajack]

Yes, we neem system-x options so that custom rust builds will work if someone is testing specific things.

[SimonSapin]

#18325 does not fix this (I think rustup should completely replace our bootstrapping mechanism eventually), but it’s a step.

[SimonSapin]

Update: rust-lang/rustup#1250 has landed in rustup master but is not in a release yet.

[SimonSapin]

Rustup 1.7.0 is released. (Thanks Alex!)

~/servo$ cargo build --manifest-path ports/servo/Cargo.toml
info: syncing channel updates for 'nightly-2017-10-13-x86_64-unknown-linux-gnu'
info: latest update on 2017-10-13, rust version 1.22.0-nightly (dcbbfb6e8 2017-10-12)
[…]
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: installing component 'rust-docs'
   Compiling percent-encoding v1.0.0
[…]