-
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
Ensure ./x.py dist
adheres to build.tools
#87282
Conversation
Do you know if there was a regression? According to issue #86436 (Unable to build 1.53.0 from official tarball due to miri) this also does not work anymore with |
Hmm, this PR doesn't change |
Overall looks good -- I think the refactor I suggested could be nice, but is also fine to leave out from this PR. I think over the last few months I've started thinking about a new design for the default/should_run system anyway, which would likely address my suggestion in a slightly better way. So unless you're feeling particularly enthusiastic about the possible cleanup, let's leave it out for the time being. I would like the first comment about tools = [] addressed though, that should be easy. |
Pushed the refactoring as well, so you can review it. I haven't tested it behaves correctly in all the cases, so let's wait until I do so before merging (reviewing is fine though). |
This comment has been minimized.
This comment has been minimized.
f6202a5
to
c15e248
Compare
The default is then overridden by `should_run`.
Ok fixed a bug I found while testing, the PR should now work as expected. r? @Mark-Simulacrum |
|
||
// Avoid running steps contained in --exclude | ||
for pathset in &should_run.paths { | ||
if desc.is_excluded(self, pathset) { |
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.
Hm -- this is going to end up printing a bunch of times that things are / are not excluded, which seems a little annoying (i.e., when this is invoked multiple times). Maybe we should make it a ensure-style query that gets its result cached...
Seems OK for this PR though, that printing is noisy anyway.
@bors r+ |
📌 Commit 69f712c has been approved by |
Rollup of 13 pull requests Successful merges: - rust-lang#86183 (Change environment variable getters to error recoverably) - rust-lang#86439 (Remove `Ipv4Addr::is_ietf_protocol_assignment`) - rust-lang#86509 (Move `os_str_bytes` to `sys::unix`) - rust-lang#86593 (Partially stabilize `const_slice_first_last`) - rust-lang#86936 (Add documentation for `Ipv6MulticastScope`) - rust-lang#87282 (Ensure `./x.py dist` adheres to `build.tools`) - rust-lang#87468 (Update rustfmt) - rust-lang#87504 (Update mdbook.) - rust-lang#87608 (Remove unused field `Session.system_library_path`) - rust-lang#87629 (Consistent spelling of "adapter" in the standard library) - rust-lang#87633 (Update compiler_builtins to fix i128 shift/mul on thumbv6m) - rust-lang#87644 (Recommend `swap_remove` in `Vec::remove` docs) - rust-lang#87653 (mark a UB doctest as no_run) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
According to
config.toml.example
, the way to produce dist artifacts for both the compiler and a subset of tools would be to enable the extended build and manually specify the list of tools to build:This works as expected for
./x.py build
and./x.py install
, but not for./x.py dist
. Before this PR./x.py dist
simply ignored the contents ofbuild.tools
, building just rustc/rustdoc ifbuild.extended = false
and all of the tools otherwise. This PR does two things:./x.py dist extended
to only build the tools defined inbuild.tools
, ifbuild.tools
is not empty. The rest of the extended step was refactored to simplify the code.assert!(builder.config.extended)
to prevent tools from being built withbuild.extended = false
, tools are simply built by default depending onbuild.extended
andbuild.tools
. This also enables to explicitly dist tools even withbuild.extended = false
.This PR is best reviewed commit-by-commit.
Fixes #86436