Steps
cargo new repro && cd repro
rustc +nightly -Z unstable-options --print target-spec-json --target x86_64-apple-darwin > x86_64-apple-darwin.json
The JSON filename should match the target to avoid some strange cases in the compiler. This should occur on other platforms as well.
Create build.rs
fn main() {
dbg!(std::env::var("TARGET"));
}
cargo +nightly build --target $PWD/x86_64-apple-darwin.json -Z build-std --verbose --verbose --verbose
The build-std
isn't really important to this issue, it's only used to support the non-standard target specification.
You'll see the TARGET
variable no longer has the path and .json
extension in the output:
[repro 0.1.0] [build.rs:2] std::env::var("TARGET") = Ok(
[repro 0.1.0] "x86_64-apple-darwin",
[repro 0.1.0] )
This caused an issue in the rust-lang/rust repository while I was trying to port to aarch64-apple-darwin
by using a JSON target file. Specifically, indexmap uses autocfg which uses TARGET
to build things.
This was failing because my target didn't yet exist in the compiler, so autocfg decided it was the wrong version of rustc
.
Possible Solution(s)
It seems like it should include the full path to the JSON file in the environment variable, but I'm not sure what the impact of such a change would be.
Notes
% cargo +nightly version
cargo 1.47.0-nightly (51b66125b 2020-08-19)
% rustc +nightly --version
rustc 1.47.0-nightly (5180f3da5 2020-08-23)
I think this was a change caused by #7425, that was perhaps unintended (or at least unnoticed by me at the time). I am uncertain if @alexcrichton intentionally chose short_name
here, or if it should be changed to rustc_target
.
Considering that JSON specs are kinda unstable, and that is how TARGET used to behave prior to 1.40, I think there is some wiggle room to change it.
Since the short name can be inferred from the path (file_stem
), then I think passing the full path is probably the best option. If something needs the short name for whatever reason (I can't immediately think of any), then it can be inferred from the path.
Does the path need canonicalization? e.g. autocfg
's working directory from a build script doesn't necessarily match the cargo invocation, right? I don't know, maybe that aspect is already covered in how it's normally passed to rustc.
The path is canonicalized here. I think the canonicalized path is the right choice (except that canonicalize
doesn't always work, but that's a separate issue).