Repository navigation
Features 2.0 meta tracking issue. #8088
Description
This is a tracking issue for a collection of changes to features that we are considering rolling out together.
- Tracking issue for -Z features=itarget #7914
-Z features=itarget— Ignoring inactive targets. - Tracking issue for -Z features=host_dep #7915
-Z features=host_dep— Decoupling features of normal deps from host deps (build dependencies and proc-macros). - Tracking issue for -Z features=dev_dep #7916
-Z features=dev_dep— Decoupling features of dev-dependencies from normal builds. - New behavior of
--feature+--packagecombination #5364-Z package-features— Better ways to select workspace features on the command-line.
The current idea is to add a flag to [workspace] to opt-in to the new behavior for all of these at once.
Reacted by Jon Gjengset, Lucio Franco, Martijn Gribnau, Geoffry Song, George Hahn, Taiki Endo, Joshua Salzedo, Blisto91, Tyler, Kornel and 14 more
Activity
alexcrichton commentedon Apr 9, 2020
For rolling out, I think I might actually propose a scheme such as:
package.cargo-features = "2020"option to the manifest."2015"(the 1.0 date)edition = "2021"comes around, that impliescargo-features = "2020"or whatever is latest by that point.cargo newto generatecargo-features = "2020"in all new packagesI think that should satisfy all our constraints, except for maybe being a nice system. The reason I propose this is the fourth bullet, though, where eventually we do not want to require this configuration and instead we will simply want to infer it from an
edition = "2021"flag. If we take that as a given,[workspace]doesn't currently have an edition flag and it'd be kind a bummer if we had to generate:in the next edition. So given that constraint that we want to infer it from
edition = "2021"eventually, then we need some sort of way of rationalizing what happens when you configure it in[package], which taking the maximum I think is reasonable-ish.ehuss commentedon Apr 9, 2020
I might be reluctant to use
cargo-features, to avoid confusion with the top-levelcargo-featureswhich is used for nightly unstable stuff.Hm, what about just allowing some
cargo-featureson stable? Like:Or we could rename that, since the word "feature" is so overloaded.
Top-level things don't work as well in a virtual manifest if we want to make it part of the next edition. Unless we move the edition field to the root.
I think with looking at every workspace member, it could be too easy to accidentally introduce a global change. Imagine a large workspace with lots of different people working on it, someone introduces a new tool or library with
cargo new, and doesn't know that the flag will affect everyone in the workspace.alexcrichton commentedon Apr 10, 2020
I would slightly prefer in terms of bikeshedding that this is placed in
[package]instead of the top-level since it feels pretty weird going at the top level (very little else does on stable), but that's a minor point.I agree that changing any package with this flag (or using
cargo newto create a new one) is weird to have the subtle effect of having a global change in the workspace. That being said though I don't know how we can get away from that. If we're 5 years down the road in the new edition and youcargo newinto a workspace you wrote today, what's supposed to happen? I guess I sort of see it as a sort of inevitability that we're going to need to accept this subtle changes-the-global-behavior behavior, or if not I think we should focus temporarily on where we want to be after the next edition and work backwards from there to how the opt-in should look today. (if that makes sense)I'm personally relatively wary of trying to make
cargo newsuper smart about workspaces and doing lots of inference about how to insert itself into a workspace (or "I would be in this workspace so let me act on that"). I do think though thatcargo newshould always default you to the "latest and greatest defaults", which ideally is one line inCargo.tomlin the limit of time with editions. I guess put another way I don't personally see a feasible way forward to upgrade the workspace incargo newto give us an alternative way to implement this in the future.Auto merge of #8129 - ehuss:resolver-behavior, r=alexcrichton
ehuss commentedon Apr 24, 2020
The new opt-in mechanism is now on nightly:
See the docs for more details: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#resolver
Amanieu commentedon Apr 25, 2020
So I just tried this out in one of my projects where I have a virtual workspace at the root and a bunch of crates in subdirectories. If I understand correctly, I only need to set the resolver in the workspace, not in the individual crates. However when I do that, I get a bunch of warnings from cargo:
Is this the expected behavior? Do I need to specifically override the resolver for all crates in the workspace?
ehuss commentedon Apr 25, 2020
Nah, it looks like the warning detection is just horribly broken. It is intended that you only specify it in the root
[workspace]. I'll try to get it fixed soon.cbiffle commentedon May 4, 2020
I left some glowing praise for the resolver 2 behavior in a comment on the
host_depbug, btw. Saved our bacon. Behaves well atnightly-2020-05-01.berkowski commentedon May 19, 2020
Seems to work for me as well in a use case similar to @cbiffle when using
bindgenas a build dependency for a firmware project cross-compiled to thumbv6m. Not willing to make the move to nightly at this point though.Auto merge of #8997 - ehuss:stabilize-features, r=alexcrichton
#1 update minimum required rust version to support new nalgebra