Langkah
cargo new repro && cd repro
rustc +nightly -Z unstable-options --print target-spec-json --target x86_64-apple-darwin > x86_64-apple-darwin.json
Nama file JSON harus sesuai dengan target untuk menghindari beberapa kasus aneh pada compiler. Ini juga harus terjadi di platform lain.
Buat 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
build-std
tidak terlalu penting untuk masalah ini, ini hanya digunakan untuk mendukung spesifikasi target non-standar.
Anda akan melihat variabel TARGET
tidak lagi memiliki jalur dan .json
ekstensi di keluaran:
[repro 0.1.0] [build.rs:2] std::env::var("TARGET") = Ok(
[repro 0.1.0] "x86_64-apple-darwin",
[repro 0.1.0] )
Ini menyebabkan masalah di repositori rust-lang / rust ketika saya mencoba mentransfer ke aarch64-apple-darwin
dengan menggunakan file target JSON. Secara khusus, indexmap menggunakan autocfg yang menggunakan TARGET
untuk membuat sesuatu.
Ini gagal karena target saya belum ada di kompiler, jadi autocfg memutuskan itu adalah versi yang salah dari rustc
.
Solusi yang memungkinkan)
Sepertinya itu harus menyertakan jalur lengkap ke file JSON dalam variabel lingkungan, tetapi saya tidak yakin apa dampak dari perubahan tersebut.
Catatan
% cargo +nightly version
cargo 1.47.0-nightly (51b66125b 2020-08-19)
% rustc +nightly --version
rustc 1.47.0-nightly (5180f3da5 2020-08-23)
Saya pikir ini adalah perubahan yang disebabkan oleh # 7425, yang mungkin tidak disengaja (atau setidaknya tidak saya perhatikan saat itu). Saya tidak yakin apakah @alexcrichton sengaja memilih short_name
sini , atau harus diubah menjadi rustc_target
.
Mempertimbangkan bahwa spesifikasi JSON agak tidak stabil, dan seperti itulah TARGET biasanya berperilaku sebelum 1,40, saya pikir ada beberapa ruang gerak untuk mengubahnya.
Karena nama pendek dapat disimpulkan dari jalur ( file_stem
), maka menurut saya meneruskan jalur lengkap mungkin merupakan opsi terbaik. Jika sesuatu membutuhkan nama pendek karena alasan apa pun (saya tidak bisa langsung memikirkannya), maka itu dapat disimpulkan dari jalurnya.
Apakah jalur tersebut memerlukan kanonikalisasi? misal, direktori kerja autocfg
dari skrip build tidak selalu cocok dengan permintaan kargo, bukan? Entahlah, mungkin aspek itu sudah tercakup dalam bagaimana biasanya diteruskan ke rustc.
Jalan tersebut dikanonikalisasi di sini . Saya pikir jalur yang dikanonikalisasi adalah pilihan yang tepat (kecuali bahwa canonicalize
tidak selalu berfungsi, tapi itu masalah terpisah).