-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Support per pkg target for -Zbuild-std
#10330
base: master
Are you sure you want to change the base?
Support per pkg target for -Zbuild-std
#10330
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) soon. Please see the contribution instructions for more information. |
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.
This looks pretty reasonable to me, thanks for this!
src/cargo/ops/cargo_compile.rs
Outdated
// TODO: This should eventually be fixed. Unfortunately it is not | ||
// easy to get the host triple in BuildConfig. Consider changing | ||
// requested_target to an enum, or some other approach. | ||
anyhow::bail!("-Zbuild-std requires --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.
I think that we still need to keep this around in one form or another. IIRC the issue has to do with where if you have cargo build
for nothing with a per-package-target or anything like that then build scripts and proc macros will do the wrong thing and try to use the custom-built libstd.
I think though that this check would need to improve because if your manifest has a per-package-target then there's no need to require --target
on the command line, so this check may just need to get deferred to later?
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.
The todo comment seems to suggest that we would like to see support for -Zbuild-std
ing the host target though, which would be supported after this change thanks to target selection overhaul in our logic.
then build scripts and proc macros will do the wrong thing and try to use the custom-built libstd.
Ah I see. Then we could avoid attaching the custom std dependencies for proc-macro and build script runs. I will write a test for this.
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.
On a second glance I don't think we should add this as a test. We can't just do -Zbuild-std=std
because then it doesn't matter if a dependent crate is proc-macro of a build script because what happens if they use the custom std?
But if we do -Zbuild-std=core
, the dependent crate will use the default sysroot instead, IIUC. (because it wants to use proc-macro and build-std
is not configured to build proc-macro
therefore it uses the installed libstd). On my local machine I did try to add some tests but it fails when I add them:
error: no matching package named `pm` found
location searched: registry `crates-io`
required by package `foo v0.1.0 (/shared/develop/cargo/target/tmp/cit/t0/foo)`
', tests/build-std/main.rs:353:70
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
proc_macro_dep_no_explicit_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.
There were a number of blockers to enabling cargo build -Zbuild-std
. This PR is one of them but it is not the only blocker, and the other blocker (that I know of at least) is that host things (build scripts and proc macros) use the custom-built std. Build scripts and proc macros should always use the host-defined std, never the custom-built std. One major use case is rebuilding the custom-built std with different codegen options that may or may not be applicable to the host (e.g. fuzz options).
I realize that requiring --target
obviates this PR somewhat, but this is not a conditional that can be unconditionally removed until this other issue in the behavior is fixed.
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'm stuck. I think we could continue the last PR but keep it also as a cli option? Then we could rewrite the logic handling each crate instead of the current way, handling the whole build.
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.
To clarify, I think "fixing" this to not actually need --target
is likely to be somewhat difficult in Cargo. I haven't looked myself to see what it might entail but I don't think it will be trivial.
Otherwise I don't have a preference to go about this. My main point is that we can't simply stop requiring --target
due to the consequence of how Cargo treats things like RUSTFLAGS
☔ The latest upstream changes (presumably #9992) made this pull request unmergeable. Please resolve the merge conflicts. |
Coming back to this, I don't believe cargo/src/cargo/core/compiler/unit_dependencies.rs Lines 159 to 168 in c9a8199
.. already avoid attaching custom std deps for host compile kinds. This means that if a user did not specify the compile kind to use for a specific unit, it will just use the host-defined std. Only when specifying a target, through |
c99ca79
to
7bd59cd
Compare
☔ The latest upstream changes (presumably #10434) made this pull request unmergeable. Please resolve the merge conflicts. |
Hi! @fee1-dead I'm really looking forward to see this change, we really need it in https://github.com/aya-rs/aya ecosystem. Could you please rebase it? |
9873dff
to
f7e023a
Compare
There seems to be a discussion up at #10330 (comment) that doesn't appear to be resolved. I don't think the Also, similar to #10405, I don't think this is a complete solution since per-package targets might come from registry dependencies. Those won't get |
@rustbot author |
☔ The latest upstream changes (presumably #10129) made this pull request unmergeable. Please resolve the merge conflicts. |
f7e023a
to
e5157f9
Compare
This makes the specific kinds to use for build-std available.
`build-std` now works with no `--target` specified to either use defaulted target or host target.
5a0b75d
to
85174f7
Compare
85174f7
to
14e8794
Compare
Okay so I did some testing and found that no @rustbot ready |
794202b
to
ea4d6df
Compare
ea4d6df
to
369a5df
Compare
☔ The latest upstream changes (presumably #9892) made this pull request unmergeable. Please resolve the merge conflicts. |
@ehuss I am unfamiliar with how artifact dependencies work and I would like this to land. Since these two are both unstable features now, could we note the certain incompatibilities and just merge it for now for further testing? |
Hm, I was perhaps not understanding the intent of the per-package-target feature. I did not realize that it doesn't work with dependencies at all. That doesn't match the motivation for the original issue (#7004), so I'm not really clear how per-package-target is intended to be used. If you or others can put some clear use cases in the tracking issue, that would be helpful. As for moving forward with this, I think that may be possible. There are still issues around resolution, features, and target-info collection. But those aren't new. Just some general feedback from a quick look:
|
Interaction with artifact dependencies can be ruled with requirement for each artifact dep to always have its target specified. Implicit behavior here can always be added later and is unclear now (should it be inherited from dependent/workspace/the package itself???) |
Fixes #9451.
cc @alexcrichton
To review this PR, you can look at the commit summaries and descriptions.