[WIP] per profile sysroot via Cargo.toml

[japaric]

This patch lets you use the 'profile.$profile.sysroot' key in Cargo.toml to pass --sysroot $path
to rustc during the compilation of the current crate and its dependencies.

Main use cases are kernel development and bare metal programming (e.g. microcontrollers) where the
application depends on a minimal set of "core" crates like core, alloc, collections, etc.
These dependencies need to be cross compiled for the target platform/architecture and a "sysroot"
(*) provides, IMO ,the cleanest way to make these core dependencies available to the many crates
that conform the application.

(*) A sysroot is basically a directory that holds the already (cross) compiled "standard" crates
(i.e. core, std, etc) that are linked to your Rust programs when you call rustc. The important
bit is that you don't explicitly spell out these dependencies in e.g. a Cargo.toml; they are
implicitly available. The fastest way to familiarize with sysroots is to explore the default sysroot
with something like tree $(rustc --print sysroot).

cc #2312

---

This is minimal PoC to start the discussion. There are a few unresolved questions.

• The RUSTFLAGS feature can also be used to pass --sysroot to rustc. Should we just use that
  feature and not implement this one?
• Does this setting belong in the project's Cargo.toml or in a project local .cargo/config?
• What happens if the user uses a relative path for the value of sysroot? Is this path relative to
  the call site or relative the root of the cargo project? Example, if the user sets 'sysroot =
  foo' in their Cargo project and then calls cargo build --manifest-path some/path/Cargo.toml
  should $(pwd)/foo or some/path/foo be used as the sysroot?

cc @alexcrichton @Zoxc

[rust-highfive]

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

[japaric]

The RUSTFLAGS feature can also be used to pass --sysroot to rustc. Should we just use that
feature and not implement this one?

IMO, the feature implemented here is way more ergonomic, mainly because it's a per profile setting.
For example, when paired with cargo-sysroot one can create a debug and a release sysroot
and use this feature to automagically swap between them:

# build sysroots
$ cargo sysroot --target $triple sysroot
$ cargo sysroot --target $triple sysroot --release
$ tail Cargo.toml
[profile.dev]
sysroot = "sysroot/debug"

[profile.release]
sysroot = "sysroot/release"

# Uses the debug-enabled sysroot
$ cargo build --target $triple

# Uses the release sysroot
$ cargo build --target $triple --release

On the other hand, the RUSTFLAGS feature doesn't provide a per profile setting so you would have to
call:

$ RUSTFLAGS='--sysroot=sysroot/debug' cargo build --target $triple

$ RUSTFLAGS='--sysroot=sysroot/release' cargo build --target $triple --release

Which is less ergonomic.

[alexcrichton]

Thanks for the PR @japaric! In terms of links this also interacts with rust-lang/rfcs#1133 in the sense that Cargo may one day grow some "smarter resolution" for cross-compiled sysroots or something like that. That RFC, however, is still quite early and probably needs some work, so I wouldn't necessarily want to block this on that.

In terms of whether this belongs in .cargo/config or Cargo.toml, the intentions for those are:

• .cargo/config - configuration that's machine specific and likely shouldn't be copied by default to anyone else.
• Cargo.toml - configuration that's project-specific and should indeed be shared with other developers.

The case of sysroot here is interesting because there's a few concerns with it:

• It is likely required to get the project to compile, which profile isn't necessarily appropriate for. The "top level package" always selects profiles, so child crates are always ignored in this regard.
• The actual location of the sysroot, however, may vary across machines.

I guess to be honest I'm not sure if we want to land this just yet or not. I definitely agree that this is more ergonomic than RUSTFLAGS, but leveraging this option is already indicative of driving Cargo from some external build system (the sysroot has to be created somehow), and in that case setting the environment variable may not be so bad?

[japaric]

driving Cargo from some external build system (the sysroot has to be created somehow), and in that case setting the environment variable may not be so bad?

Now that RUSTFLAGS is a thing, I created a cargo wrapper that can be used just like cargo: xargo build --target $custom_target but it takes care of building/maintaining the sysroot and setting the RUSTFLAGS variable without user intervention. It addresses my ergonomics concern, so I'm going to close this.

Thanks for sharing your thoughts @alexcrichton!