feat: Expost host and target sysroot to build scripts.

[c272]

What does this PR try to resolve?

Currently, when using -Zbuild-std, Cargo passes a --sysroot argument down to the relevant rustc invocations. However, the value of this argument is not exposed to build scripts, so if a build script wishes to mirror the rustc configuration of the host, they must somehow discover the sysroot themselves.

This patch exposes the host (RUSTC_HOST_SYSROOT) and target (RUSTC_TARGET_SYSROOT) sysroots to build scripts through additional environment variables.

Fixes #7501 Related to https://github.com/rust-lang/wg-cargo-std-aware/issues/50

How should we test and review this PR?

An example build script displaying these environment variables is as follows:

use std::env;

fn main() {
    println!("host: {}", env::var("RUSTC_HOST_SYSROOT").unwrap());
    println!("target: {}", env::var("RUSTC_TARGET_SYSROOT").unwrap());
}

Additional information

N/A

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @weihanglo (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[weihanglo]

Sorry I don't quite follow. I read through the relevant issues but haven't found any design decision made. Do we have discussions in other places like Zulip I missed?

[weihanglo]

Asking because we would like to have design discussions in issue threads, and PRs is for discussing each implementation separately. That would make things a bit easier to follow :)

[adamgemmell]

Hi, sorry about that! I advised c272 to share the implementation first as the best way to move the discussion forwards. We should have followed the contributor's guide a bit more closely - hope it didn't seem too pushy.

Writing the patch fleshed this idea out a bit more in the process, so one of us will share that in a separate feature request issue.

[bors]

:umbrella: The latest upstream changes (presumably #13409) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

:umbrella: The latest upstream changes (presumably #13872) made this pull request unmergeable. Please resolve the merge conflicts.