-
Notifications
You must be signed in to change notification settings - Fork 459
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Cargo's target information when possible #1225
Conversation
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure leave it to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could merge it in as-is and then I can open a separate PR to optimize it.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well...I think we need to do this, this change might break some use cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for all the hard work!
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
cc
depend more onrustc
's linker knowledge instead of the other way around.Part of #1120.
Builds upon #1224.