-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Change bootstrap's tool.TOOL_NAME.features
to work on any subcommand
#143733
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
Conversation
12c179f
to
63d0487
Compare
Nice improvement! Any particular reason for matching tools also by path though? |
As far as I can understand tools are identified by their path, not by their name, e.g. here the descriptions don't contain a name (the "name" field is the fully qualified name of the class, so it does not count): rust/src/bootstrap/src/core/builder/mod.rs Line 938 in 78a6e13
I read the code that is used to match |
Hmm, I wouldn't say that they are identified by path, but I guess it depends on how you define "identified" :) In the |
I don't feel strongly either way; since you're already looking at this, r? @Kobzol |
|
// build.tool.TOOL_NAME.features in bootstrap.toml allows specifying which features to enable | ||
// for a specific tool. `extra_features` instead is not controlled by the toml and provides | ||
// features that are always enabled for a specific tool (e.g. "in-rust-tree" for rust-analyzer). | ||
// Finally, `prepare_tool_cargo` above here might add more features to adapt the build | ||
// to the chosen flags (e.g. "all-static" for cargo if `cargo_native_static` is true). | ||
builder | ||
.config | ||
.tool | ||
.iter() | ||
.filter(|(tool_name, _)| path.ends_with(tool_name)) | ||
.for_each(|(_, tool)| features.extend(tool.features.clone().unwrap_or_default())); |
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.
Discussion: if not already present, maybe we should remark that enabling features in tools which are not part of the internal "extra-features" preset might not always work?
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.
Ok thanks, I added a comment to bootstrap.example.toml
I'm fine with the change, but I'd like to just use the tool name, it's established practice in bootstrap, and I don't think we have a use-case to do it differently here. |
This PR modifies If appropriate, please update |
Yeah makes sense, I changed the code to compare the tool name to only the last part of the path (aka the filename). Thanks for the review :-) |
Thanks! @bors r+ rollup |
☔ The latest upstream changes (presumably #143888) made this pull request unmergeable. Please resolve the merge conflicts. |
Rollup of 8 pull requests Successful merges: - #142885 (core: Add `BorrowedCursor::with_unfilled_buf`) - #143217 (Port #[link_ordinal] to the new attribute parsing infrastructure) - #143355 (wrapping shift: remove first bitmask and table) - #143448 (remote-test-client: Exit code `128 + <signal-number>` instead of `3`) - #143724 (Tidy cleanup) - #143820 (Fixed a core crate compilation failure when enabling the `optimize_for_size` feature on some targets) - #143850 (Compiletest: Simplify {Html,Json}DocCk directive handling) - #143880 (tests: Test line debuginfo for linebreaked function parameters) Failed merges: - #143630 (Drop `./x suggest`) - #143733 (Change bootstrap's `tool.TOOL_NAME.features` to work on any subcommand) r? `@ghost` `@rustbot` modify labels: rollup
d3e332e
to
940aa20
Compare
@rustbot ready |
@bors r+ |
Rollup of 10 pull requests Successful merges: - #143217 (Port #[link_ordinal] to the new attribute parsing infrastructure) - #143681 (bootstrap/miri: avoid rebuilds for test builds) - #143724 (Tidy cleanup) - #143733 (Change bootstrap's `tool.TOOL_NAME.features` to work on any subcommand) - #143850 (Compiletest: Simplify {Html,Json}DocCk directive handling) - #143875 (update issue number for `const_trait_impl`) - #143881 (Use zero for initialized Once state) - #143887 (Run bootstrap tests sooner in the `x test` pipeline) - #143917 (Change "allocated object" to "allocation".) - #143918 (Tier check cleanup) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of #143733 - Stypox:bootstrap-tool-config-any, r=Kobzol Change bootstrap's `tool.TOOL_NAME.features` to work on any subcommand This is a followup to #142379 to make the bootstrap option `tool.TOOL_NAME.features` work on any subcommand instead of just build (so also run/test/...). I also made the `TOOL_NAME` comparisons look at the tool path instead of the tool name to determine to which tool a `TOOL_NAME` refers to, so you can specify tools by path like in other places of the bootstrap (e.g. `tool."tools/miri".features`).
This is a followup to #142379 to make the bootstrap option
tool.TOOL_NAME.features
work on any subcommand instead of just build (so also run/test/...). I also made theTOOL_NAME
comparisons look at the tool path instead of the tool name to determine to which tool aTOOL_NAME
refers to, so you can specify tools by path like in other places of the bootstrap (e.g.tool."tools/miri".features
).