Use Cargo's target information when possible #1225
Conversation
madsmtm
force-pushed
the
parse-targets
branch
from
7ecc76a
to
2fa692d
Compare
rustc's target triples generally only have a vague resemblance to each other and to the information needed by `cc`. Let's instead prefer `CARGO_CFG_*` variables when available, since these contain the information directly from the compiler itself. In the cases where it isn't available (i.e. when running outside of a build script), we fall back to parsing the target triple, but instead of doing it in an ad-hoc fashion with string manipulation, we do it in a more structured fashion up front.
madsmtm
force-pushed
the
parse-targets
branch
from
2fa692d
to
0b60b02
Compare
|
I've now gone through my own FIXMEs, and opened PRs against
|
|
I've implemented the approach discussed in #1225 (comment) now. |
| /// | ||
| /// This differs from `cfg!(target_arch)`, which only specifies the | ||
| /// overall architecture, which is too coarse for certain cases. | ||
| pub full_arch: Cow<'static, str>, |
There was a problem hiding this comment.
I think we can just use &'a str here, it'd be simpler and a smaller struct.
For from_cargo_environment_variables, we can cache the environment variables in cc::Build so that we can return a Target<'_>, we already do env caching so this is not a problem.
We can use the homebrew OnceLock impl within our codebase, so that we could avoid lifetime problems with MutexGuard/RwLockGuard.
There was a problem hiding this comment.
P.S. I'm not worried/obsessed about the allocation as it doesn't matter much, I just prefer a simpler structure.
Caching the env var in Build would also be consistent with how other env var currently works:
Once we read the env var from system into Build, it's never changed in that object and any objects created by Build::clone.
There was a problem hiding this comment.
Hmm, I don't see how OnceLock would help with avoiding a guard? Do you mean to store cached environment variables in a global instead?
There was a problem hiding this comment.
You can put OnceLock inside cc::Build struct.
For example:
struct Build {
target_triple: Arc<OnceLock<String>>,
// ...
}store individual fields of Target directly in it, and return Target<'_> with a lifetime.
Arc is used to be consistent with existing env cache code.
There was a problem hiding this comment.
Hmm, I'm still not entirely sure I get what you want me to do, and I feel like it'd make the code more convoluted? (I'm somewhat trying to move things out of the huge Build struct).
Would you mind doing it?
madsmtm
force-pushed
the
parse-targets
branch
from
c212003
to
ae310a3
Compare
| fn is_wasi_target(target: &str) -> bool { | ||
| const TARGETS: [&str; 7] = [ | ||
| "wasm32-wasi", | ||
| "wasm32-wasip1", | ||
| "wasm32-wasip1-threads", | ||
| "wasm32-wasip2", | ||
| "wasm32-wasi-threads", | ||
| "wasm32-unknown-wasi", | ||
| "wasm32-unknown-unknown", | ||
| ]; | ||
| TARGETS.contains(&target) | ||
| } |
There was a problem hiding this comment.
Cross-referencing #1126, I've replaced usage of is_wasi_target with target.os == "wasi" in this PR, but that of course won't catch wasm32-unknown-unknown - so there might now be places where instead of target.os == "wasi", the correct check would be target.arch == "wasm32" || target.arch == "wasm64"
rustc's target triples generally only have a vague resemblance to each other and to the information needed by
cc. Let's instead preferCARGO_CFG_*variables when available, since these contain the information directly from the compiler itself.In the cases where it isn't available (i.e. when running outside of a build script), we fall back to parsing the target triple, but instead of doing it in an ad-hoc fashion with string manipulation, we do it in a more structured fashion up front.
Fixes #1219 (at least my main gripe with the current implementation).
Closes #693 by making
ccdepend more onrustc's linker knowledge instead of the other way around.Part of #1120.
Builds upon #1224.