-
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
, take two
#11969
base: master
Are you sure you want to change the base?
Support per-pkg-target
for -Zbuild-std
, take two
#11969
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. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
7afcaea
to
11bf15f
Compare
This is a simplified minimal change, which changes the build-std to iterate over the packages to collect a list of targets std should be built for. Does the iterating over packages part have issues with artifact dependencies? I am not very familiar with artifact deps to know so any help would be appreciated. But it should be fine for now since artifact dependencies don't work with build-std yet. rust-lang#10444
11bf15f
to
c49c40b
Compare
// Passing `build_config.requested_kinds` instead of | ||
// `explicit_host_kinds` here so that `generate_root_units` can do |
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's a comment that looks like it needs to be updated here due to the removal of explicit_host_kinds
.
@@ -227,3 +227,50 @@ fn custom_test_framework() { | |||
.build_std_arg("core") | |||
.run(); | |||
} | |||
|
|||
/// like cross-custom but uses per-package-target instead | |||
#[cargo_test(build_std_real)] |
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.
Can you say why this needs to be a real build-std test? I would prefer to avoid those if possible. The mock tests should be able to use .arg("target").arg(alternate())
and use the alternate
function to specify a target different from the host (and not using a JSON target).
name = "foo" | ||
version = "0.1.0" | ||
edition = "2018" | ||
default-target = "custom-target.json" |
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 don't think this is testing this target. Because build-std requires --target to be specified, the default target is never used. I might suggest using forced-target
.
.build(); | ||
|
||
p.cargo("build -v") | ||
.build_std_arg("core") |
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.
Preferably this would contain a with_stderr
to validate that the --target
flag is being passed correctly for each invocation.
// Don't re-export everything in the root so that the mock std can be distinguished from the real one. | ||
#[stable(since = "1.0.0", feature = "dummy")] | ||
pub use proc_macro::*; | ||
pub mod exported { | ||
#[stable(since = "1.0.0", feature = "dummy")] | ||
pub use proc_macro::*; | ||
} |
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.
Can you clarify why this is needed?
In general, I'm not seeing the connection with proc-macro changes and support for per-pkg-target.
.file( | ||
"Cargo.toml", | ||
r#" | ||
[package] | ||
name = "pm" | ||
version = "0.1.0" | ||
[lib] | ||
proc-macro = true | ||
"#, | ||
) |
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.
Can you say why this was added?
p.cargo("build -v") | ||
.build_std(&setup) | ||
.target_host() | ||
.run_expect_error(); |
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 should use with_status()
, and also have with_stderr()
to verify which error is happening.
Also, similar to the other questions, I'm not clear why this should fail. What's wrong with having a library access the proc_macro crate?
I think this should be fine to move forward with, but I'm a little concerned that this is ultimately not the correct way for this information to be gathered. The set of targets influences feature resolution, so the collection will need to be done before the standard library is resolved. So from a very high level:
One thing I would like to note, not required for this PR, is that I often have difficulty tracking which circumstances are allowed to have |
@rustbot author |
☔ The latest upstream changes (presumably #13065) made this pull request unmergeable. Please resolve the merge conflicts. |
This is a simplified minimal change, which changes the build-std to iterate over the packages to collect a list of targets std should be built for. Does the iterating over packages part have issues with artifact dependencies? I am not very familiar with artifact deps to know so any help would be appreciated. But it should be fine for now since artifact dependencies don't work with build-std yet. #10444