Proposal
Add --print=llvm-target-tuple to print the target tuple that should be passed to clang and other llvm tools.
> rustc --print=llvm-target-tuple --target aarch64-kmc-solid_asp3
aarch64-unknown-none
> rustc --print=llvm-target-tuple --target bpfeb-unknown-none
bpfeb
Motivation
cc-rs needs to figure out how to invoke the C compiler for the current target. To do this it gathers information about the target (such as the target_arch, target_env, etc) and infers the right flags to pass to the C compiler based on that.
Almost all of this information is available via --print=cfg and therefore CARGO_TARGET_CFG_* environment variables in build scripts. However, noticeably missing is the llvm target tuple which is only available via the unstable --print=target-spec-json. This is needed to pass to clang when cross-compiling.
Currently cc-rs is forced to either guess or use a lookup table to discern the current target's llvm tuple. This should ideally be unnecessary because rustc already knows what the llvm target tuple should be (at least with the llvm backend). But there's no (stable) way for cc-rs to get at this information. This is especially important for custom targets where we can only guess at the llvm target tuple.
A useful followup to this MCP would be to add a cargo build script environment variable with this information. But that's a matter for the cargo team.
Alternatives
- The llvm target tuple could be added to
--print=cfg but this would be awkward because it would also imply being a #[cfg] conditional compilation value.
- There could be some way for
cc-rs (and other crates) to query for the arguments the platform's C compiler(s) need. This would require adding that information to rustc (or a tool shipped with rustc).
Mentors or Reviewers
Process
The main points of the Major Change Process are as follows:
You can read more about Major Change Proposals on forge.
Proposal
Add
--print=llvm-target-tupleto print the target tuple that should be passed to clang and other llvm tools.Motivation
cc-rsneeds to figure out how to invoke the C compiler for the current target. To do this it gathers information about the target (such as thetarget_arch,target_env, etc) and infers the right flags to pass to the C compiler based on that.Almost all of this information is available via
--print=cfgand thereforeCARGO_TARGET_CFG_*environment variables in build scripts. However, noticeably missing is the llvm target tuple which is only available via the unstable--print=target-spec-json. This is needed to pass toclangwhen cross-compiling.Currently
cc-rsis forced to either guess or use a lookup table to discern the current target's llvm tuple. This should ideally be unnecessary becauserustcalready knows what the llvm target tuple should be (at least with the llvm backend). But there's no (stable) way for cc-rs to get at this information. This is especially important for custom targets where we can only guess at the llvm target tuple.A useful followup to this MCP would be to add a cargo build script environment variable with this information. But that's a matter for the cargo team.
Alternatives
--print=cfgbut this would be awkward because it would also imply being a#[cfg]conditional compilation value.cc-rs(and other crates) to query for the arguments the platform's C compiler(s) need. This would require adding that information torustc(or a tool shipped withrustc).Mentors or Reviewers
Process
The main points of the Major Change Process are as follows:
@rustbot second.-C flag, then full team check-off is required.@rfcbot fcp mergeon either the MCP or the PR.You can read more about Major Change Proposals on forge.