Rust sysroot is not exposed to build scripts

[jdm]

When building with wrappers like xargo or the new -Z build std flag, rustc invocations get a --sysroot [something] flag passed to them. Any build scripts that rely on running a new rustc invocation that matches the current build configuration as closely as possible (such as autocfg is out of luck, because replicating the sysroot needs to be done manually. If the sysroot path were exposed through a RUST_SYSROOT environment variable to build scripts then this would be easier to deal with.

[roblabla]

Instead of (or in addition to) a RUST_SYSROOT, what I would really like is for a separate flags containing the proper CLI arguments to pass to rustc to be provided to build scripts. In autocfg, there's a PR open to support xargo by looking at the RUSTFLAGS, but it's an incomplete solution because we can't differentiate from someone building with a custom sysroot with TARGET = HOST (which should use RUSTFLAGS) and someone building a proc_macro/build script (which shouldn't use RUSTFLAGS).

Ideally, we'd have a CARGO_RUSTFLAGS key containing the result of

cargo/src/cargo/core/compiler/build_context/target_info.rs

Line 396 in 69aea5b

fn env_args(

+ whatever other flags are injected by cargo for sysroot and other stuff.

[janderholm]

I'd like to point out that there may be more than one sysroot. Many (most?) cross compilation environments such as openembedded keeps the binaries and libraries for BUILD separate from that of HOST, where BUILD is the architecture of the building machine and HOST is the machine supposed to run the code.

It isn't expected that all targets share path in the way that rustup sets things up. For this reason I don't think it's enough with only one environment variable specifying one sysroot.

It is perfectly possible today to set up a different sysroot per target by using a .cargo/config file. There's also a general build.rustflags which can be used but it doesn't seem to be passed to rustc when compiling build scripts while also cross compiling.

[cuviper]

The build script would be invoked separately for each target though, so such environment variables can be provided specific to each.

[epage]

#11244 also includes discussion on build probes.

[epage]

Closing for similar reason as #11244

We talked about this in today's cargo meeting. The use cases seem to be focused on build probes. We are not inclined to add features specifically for build probes at this time but would instead encourage use of

* `cfg(accessible)` and `cfg(version)` where possible (interest from t-lang to stabilize, just needs a champion to check it over and drive stabilization)

* `features` everywhere else (or maybe even [global features](https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618)), including enabling of nightly features

While cfg(accessible), cfg(version), and global features would involve MSRV bumps, I suggest considering whether the soon-to-stabilize MSRV-aware resolver might be sufficient to re-evaluate an MSRV policy in light of a feature like this. For a foundational package, one could bump minor and leave room for critical patches of old versions while allowing new versions to use these features.