-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
bootstrap: Always build for host, even when target is given #77133
Conversation
src/bootstrap/config.rs
Outdated
config.hosts = if let Some(arg_host) = flags.host { | ||
arg_host | ||
} else if let Some(file_host) = build.host { | ||
file_host.iter().map(|h| TargetSelection::from_user(h)).collect() | ||
} else { | ||
vec![config.build] | ||
}; | ||
// If host was explicitly given an empty list, don't run any host-only steps. | ||
config.skip_only_host_steps = config.hosts.is_empty(); |
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 shouldn't be necessary anymore, the field should be removable with no effect.
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 tried that at first but it changed the dist behavior in the test: it causes us to distribute a rustc for the build target ("A" in the test) as well as sources. Is that desirable?
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's probably because the tests are always configuring the build triple as part of the host triples, whereas here that's not the case -- https://github.com/Mark-Simulacrum/rust/blob/4de836e2141c418d37e556bc80c4ad0127d74b71/src/bootstrap/builder/tests.rs#L23-L26.
We should, I think, remove this field and update the tests to avoid that buggy behavior (probably by explicitly adding the build triple to all of the tests that need it, i.e., those that don't explicitly override skip_only_host_steps.
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.
Ah that makes sense, done. I also made them list all their targets explicitly for consistency.
Could you also add a note to the CHANGELOG? https://github.com/rust-lang/rust/blob/master/src/bootstrap/CHANGELOG.md No need to add a new version, just append to the list of changes. r=me with that done. |
Hm, actually, no -- I think this probably also means that we need to go and update a bunch of our builders to explicitly pass I'm not sure if this is a sign we're "doing the wrong thing" or not -- I think probably no, because in most cases you do want to test or distribute for both targets and hosts, just in our CI the way we parallelize things we want to avoid that because we're taking care of the host part in one place and then spreading the targets out. |
Should we consider it a breaking change though? |
Hm, it's a good question. I guess the answer is probably yes. It should be relatively easy to bump the version number -- I think just https://github.com/rust-lang/rust/blob/master/src/bootstrap/bin/main.rs#L30 needs to change but not 100% sure. cc @jyn514 as well |
You also need to add it to the changelog itself: https://github.com/rust-lang/rust/blob/master/src/bootstrap/CHANGELOG.md. Those should be the only two places I think. |
Another use case for https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/x.2Epy.20CI.20defaults ;) |
I don't think defaults would be a good fit here, they would probably confuse things more than help - better to have both overriden in the same place. |
Hmm, thinking about this more and I'm pretty on the fence about what to do. For config.toml it seems like we're reverting back to what we had 1-2 weeks ago, so having people bump For the command line we could consider it a breaking change, but we could also say that building more than we used to in some cases isn't actually breaking. Still, we do want people who might be impacted to know about it. |
114c806
to
abee146
Compare
Would it help if instead of a binary breaking/not-breaking you printed a short description of the change? |
Do you mean in the changelog? Or in A changelog entry would probably look something like:
|
I meant in check_version. In general I think nagging more is better than nagging less. The thing to avoid is people changing the number without reading the changelog, and I don't think we've had enough changes for that yet. |
abee146
to
631bd06
Compare
Right, and because these changes are "live" as soon as they merge, I think we're always going to have the issue of there being only a single change for each version. Which means we might want to tweak the changelog format a bit. Maybe grouping changes by month would make sense? I do like the idea of sticking the change text in |
631bd06
to
2826235
Compare
Okay, updated the changelog and bumped the version. Outputting breaking changes from x.py and adding an "ack" feature would be good for a follow up change. |
@Mark-Simulacrum I'll let you take a final look since I updated all the CI scripts |
☔ The latest upstream changes (presumably #77224) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
Looks like you need |
Trying to fix a problem in CI. Maybe some version of Docker is not passing '' args correctly?
Strange, maybe some version of Docker wasn't passing through empty @bors r=Mark-Simulacrum rollup=never |
📌 Commit 63eaa60 has been approved by |
⌛ Testing commit 63eaa60 with merge cd6acf7a460fd4dd80f83443261995d6907c07b7... |
💔 Test failed - checks-actions |
I want this to be a spurious error but it probably isn't. Maybe there's a subtle change in the behavior that we haven't accounted for. |
Well, one immediate problem is that
We should probably just filter out empty strings in the split function in flags.rs, that seems to have fixed that failure locally for me at least. |
Nice catch! I seem to have forgotten that I can reproduce these locally with Docker. |
Pushed a change with your suggestion. |
That said the build still fails for me locally with zlib.h header missing, but not sure if that's related to this PR. I think it might be changes to the docker environment or something like that, because adding zlib1g-dev to the armhf-gnu docker container does seem to fix things. Maybe an upstream change to 16.04? Seems unlikely, but not entirely implausible, and I'm fine with hitting CI to find out. |
TIL about carp streamer, https://codepoints.net/U+1F38F, though how that relates to "flags" beyond some visual similarity I'm not sure. Anyway, @bors r+ rollup=never |
📌 Commit bf7aeaa has been approved by |
☀️ Test successful - checks-actions, checks-azure |
…orino Update `changelog-seen` in config.toml.example This got out of sync when the version was bumped last time in rust-lang#77133 Long-term we may want to find an easier way to maintain this that doesn't require bumping the version in three different places. Off the top of my head I can't think of anything, though. It _is_ documented in src/bootstrap/README.md, although I don't know how many people read that. r? @Mark-Simulacrum cc @spastorino
…orino Update `changelog-seen` in config.toml.example This got out of sync when the version was bumped last time in rust-lang#77133 Long-term we may want to find an easier way to maintain this that doesn't require bumping the version in three different places. Off the top of my head I can't think of anything, though. It _is_ documented in src/bootstrap/README.md, although I don't know how many people read that. r? @Mark-Simulacrum cc @spastorino
This changes the behavior from not building for host whenever an
explicit target is specified. I find this much less confusing.
You can still disable host steps by passing an explicit empty list for
host.
Fixes #76990.
r? @Mark-Simulacrum