Host tuple available without build.rs

[kornelski]

Proposal

Problem statement

Programs can't get the host tuple/target triple they've been built for without running build.rs

std::env::consts has some information about the host, but not enough reconstruct the full tuple.

Motivating examples or use cases

Tools that work with rustc, Cargo or rustdoc usually need to support --target and emulate default behavior of building for the host if --target is not specified.

However, the actual value of the host tuple is not easy to get. The workaround for this is to save TARGET from build.rs, but build scripts are relatively heavy, and Cargo would like to minimize need for them: rust-lang/cargo#14948

Solution sketch

rust-lang/rust#146296

Alternatives

There are cfg!(target_*) macros that makes fragments of the tuple available already, but their values are not easily available. Maybe if cfg's could be readable as values, and target cfg existed, then some cfg_value!(target).

Links and related work

rust-lang/rust#146295

https://docs.rs/current_platform/0.2.0/current_platform/ / https://crates.io/crates/current_platform

[tgross35]

This is the API in the PR:

// std::env::consts

pub const HOST: &str;

[tgross35]

One nonblocking note is that this would be useful on no_std as well, but there is no core::env. If there is a reasonable home in core, the ARCH constant would make sense to have there too.

[kennytm]

Maybe if cfg's could be readable as values, and target cfg existed, then some cfg_value!(target).

the same config key may be defined multiple times so cfg_value!(k) may not have a unique value.

$ rustc --print cfg
...
target_arch="x86_64"
target_endian="little"
target_env="gnu"
target_family="unix"
target_feature="fxsr"
target_feature="sse"
target_feature="sse2"
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="64"
target_has_atomic="8"
target_has_atomic="ptr"
...

it may work if you have a cfg_value!(k) = "v" if there is a unique k="v" (error otherwise), and another cfg_values!(k) = &["v1", "v2", "v3"] for the general cases.

[joshtriplett]

cc @epage; I think we should find a way to make this work with proposed mechanisms for typed cfg operations, so they can both use the same mechanism.

[epage]

This links to rust-lang/cargo#14948. Another possibility is cargo sets TARGET on the regular rustc call, and not just for the build script. Unsure why some of those variables are restricted.

The name HOST came out of the discussion at rust-lang/rust#146296 (comment). For me, that name is confusing as it could mean the host used for compilation or the host it is executing within which can be different than the target tuple used for compilation, even without emulation (the host system isn't musl based but I can run musl compiled code).

Maybe if cfg's could be readable as values, and target cfg existed, then some cfg_value!(target).

I believe T-compiler generally pushes back against making target tuples available for conditional compilation, which is what cfg is primarily for, due to stability issues around target tuples. This came up in #3759.

the same config key may be defined multiple times so cfg_value!(k) may not have a unique value.

https://github.com/rust-lang/rfcs/blob/4551bbd827eb84fc6673ac0204506321274ea839/text/3857-cfg-version.md#provide-a-way-to-get-a---cfgs-value talks through some considerations for cfg_value! / cfg_values!.