Extend -Zpackage-features with more capabilities.#8074
Extend -Zpackage-features with more capabilities.#8074bors merged 2 commits intorust-lang:masterfrom
Conversation
|
r? @Eh2406 (rust_highfive has picked a reviewer for you, use r? to override) |
alexcrichton
left a comment
There was a problem hiding this comment.
Nice!
So as we go further down this path I'm thinking more about the roll-out story for this. What would you think of removing all the various -Z flags we have today and instead roll everything into something like -Zfeatures2 for a "features 2.0 feature". Or, perhaps better yet, move it into the manifest as a cargo-features-gated field in [package]?
I'm basically curious if we can move closer to "all we need to do is flip a switch" territory with something we're comfortable rolling out. I'm worried now that to understand the full story of how we envision enabling all this you've gotta understand a lot of various -Z flags and how they interact
| enables matching features. It is still an error if none of the packages | ||
| define a given feature. | ||
| * `--features` and `--no-default-features` are now allowed in the root of a | ||
| virtual workspace. |
There was a problem hiding this comment.
To confirm, these flags, when applied in this scenario, would be applied to all workspace members, right?
src/cargo/core/features.rs
Outdated
| pub avoid_dev_deps: bool, | ||
| pub minimal_versions: bool, | ||
| pub package_features: bool, | ||
| pub package_features2: bool, |
There was a problem hiding this comment.
Are you worried about breakage if we change the existing unstable feature package_features? I'd be ok with simply updating that since we're more likely to stabilize this than that.
There was a problem hiding this comment.
I'm fine with merging them (will do that soonish). I wanted to get feedback first, and keeping them separate was a way to highlight how they differ.
|
Oh I should also mention that these proposed semantics for the |
Yea, that's the eventual plan. I could accelerate that, maybe after merging this? I was keeping them separate because each option had different implementation concerns and trade-offs. I think we discussed earlier of making it a flag in the However, Those concerns may not be dealbreakers. I think we should sooner or later support nested workspaces. And I think |
|
Oh sure yeah no need to conflate it here. I'm largely just worried that it's difficult to get real-world impact data/testing given the changing set of flags over time, but hey that's to be expected while things are worked on :) Perhaps we should start a dedicated issue for how to roll out the new features features? |
|
I pushed an update removing the new I also added a comment on the old tracking issue to try to solicit feedback. Filed #8088 for a meta-tracking issue. |
|
@bors: r+ 👍 |
|
📌 Commit 54ace8a has been approved by |
|
☀️ Test successful - checks-azure |
|
Yes. This is the solution to all of them, unless you see something that is not covered? |
|
I might be mistaken, but I believe normally issues are not closed until the feature is stabilized? |
Update cargo 12 commits in 390e8f245ef2cd7ac698b8a76abf029f9abcab0d..74e3a7d5b756d7c0e94399fc29fcd154e792c22a 2020-04-07 17:46:45 +0000 to 2020-04-13 20:41:52 +0000 - Update dependencies to support illumos target (rust-lang/cargo#8093) - Whitelist another known spurious curl error (rust-lang/cargo#8102) - Fix nightly test matching rustc "warning" output. (rust-lang/cargo#8098) - Update default for codegen-units. (rust-lang/cargo#8096) - Fix freshness when linking is interrupted. (rust-lang/cargo#8087) - Add `cargo tree` command. (rust-lang/cargo#8062) - Add "build-finished" JSON message. (rust-lang/cargo#8069) - Extend -Zpackage-features with more capabilities. (rust-lang/cargo#8074) - Disallow invalid dependency names through crate renaming (rust-lang/cargo#8090) - Use the same filename hash for pre-release channels. (rust-lang/cargo#8073) - Index the commands section (rust-lang/cargo#8081) - Upgrade to mdBook v0.3.7 (rust-lang/cargo#8083)
This is a proposal to extend
-Zpackage-featureswith new abilities to change how features are selected on the command-line. Seeunstable.mdfor documentation on what it does.I've contemplated a variety of ways we could transition this to stable. I tried a few experiments trying to make a "transition with warnings" mode, but I'm just too concerned about breaking backwards compatibility. The current way is just fundamentally different from the new way, and I think it would be a bumpy ride to try to push it.
The stabilization story is that the parts of this that add new functionality (feature flags in virtual worskpaces, and
member/featsyntax) can be stabilized at any time. The change forcargo build -p member --features featin a different member's directory can maybe be part of-Zfeaturesstabilization, which will need to be opt-in. I've been trying to come up with some transition plan, and I can't think of a way without making it opt-in, and making it part of-Zfeaturesis an opportunity to simplify things. One concern is that this might be confusing (--featuresflag could behave differently in different workspaces, and documenting the differences), but that seems hard to avoid.Closes #6195
Closes #4753
Closes #5015
Closes #4106
Closes #5362