Pasos
cargo new repro && cd repro
rustc +nightly -Z unstable-options --print target-spec-json --target x86_64-apple-darwin > x86_64-apple-darwin.json
El nombre del archivo JSON debe coincidir con el objetivo para evitar algunos casos extraños en el compilador. Esto también debería ocurrir en otras plataformas.
Crear 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
El build-std
no es realmente importante para este problema, solo se usa para admitir la especificación de destino no estándar.
Verá que la variable TARGET
ya no tiene la ruta y la extensión .json
en la salida:
[repro 0.1.0] [build.rs:2] std::env::var("TARGET") = Ok(
[repro 0.1.0] "x86_64-apple-darwin",
[repro 0.1.0] )
Esto causó un problema en el repositorio rust-lang / rust mientras intentaba migrar a aarch64-apple-darwin
usando un archivo de destino JSON. Específicamente, indexmap usa autocfg que usa TARGET
para construir cosas.
Esto estaba fallando porque mi objetivo aún no existía en el compilador, por lo que autocfg decidió que era la versión incorrecta de rustc
.
Soluciones posibles)
Parece que debería incluir la ruta completa al archivo JSON en la variable de entorno, pero no estoy seguro de cuál sería el impacto de tal cambio.
Notas
% cargo +nightly version
cargo 1.47.0-nightly (51b66125b 2020-08-19)
% rustc +nightly --version
rustc 1.47.0-nightly (5180f3da5 2020-08-23)
Creo que este fue un cambio causado por el # 7425, que quizás no fue intencional (o al menos pasó desapercibido para mí en ese momento). No estoy seguro de si @alexcrichton eligió intencionalmente short_name
aquí , o si debería cambiarse a rustc_target
.
Teniendo en cuenta que las especificaciones JSON son un poco inestables, y así es como se comportaba TARGET antes de la 1.40, creo que hay un margen de maniobra para cambiarlo.
Dado que el nombre corto se puede inferir de la ruta ( file_stem
), creo que pasar la ruta completa es probablemente la mejor opción. Si algo necesita el nombre corto por cualquier motivo (no puedo pensar en ninguno de inmediato), entonces se puede inferir de la ruta.
¿El camino necesita canonicalización? por ejemplo, el directorio de trabajo de autocfg
de un script de compilación no coincide necesariamente con la invocación de carga, ¿verdad? No lo sé, tal vez ese aspecto ya esté cubierto en cómo se pasa normalmente a rustc.
El camino se canoniza aquí . Creo que la ruta canonicalizada es la elección correcta (excepto que canonicalize
no siempre funciona, pero eso es un problema aparte).