Cargo: Allow specifying dependencies per feature
Most feature-dependency correspondences can currently be modeled by making the dependency optional but having the feature depend on this.
This is not possible (from what I see) if "feature-a" and "feature-b" depend on the same crate but in different versions, as each crate can only be specified once.
A syntax like the following would seem consistent for that case (and could also provide another way of specifying feature-dependant dependencies in general).
[target.'cfg(feature = "feature-a")'.dependencies]
foobar = "0.1"
[target.'cfg(feature = "feature-b")'.dependencies]
foobar = "0.2"
sdroege
All 3 comments
I think that this may also largely be supported by https://github.com/rust-lang/cargo/issues/5653? May make it a bit easier to specify as well!
alexcrichton
on 31 Aug 2018
@alexcrichton There might be dependencies that are relevant only for a certain feature. Is there a way to express that?
Edit:
There is already an example in the doc:
https://doc.rust-lang.org/cargo/reference/manifest.html#the-features-section
updogliu
on 8 May 2019
Encountered a similar issue where a workspace is split into multiple sub-crates, and each rely on specifying shared features of the main crate dependency. Something like this doesn't seem to work at all:
[features]
default = [ "fwupd", "system76" ]
fwupd = []
system76 = []
[target.'cfg(all(not(feature = "fwupd"), feature = "system76"))'.dependencies]
firmware-manager = { path = "../", default-features = false, features = [ "system76" ] }
[target.'cfg(all(feature = "fwupd", not(feature = "system76")))'.dependencies]
firmware-manager = { path = "../", default-features = false, features = [ "fwupd" ] }
[target.'cfg(all(feature = "fwupd", feature = "system76"))'.dependencies]
firmware-manager = { path = "../", default-features = false, features = [ "fwupd", "system76" ] }
cargo build --manifest-path gtk/Cargo.toml --no-default-features --features system76
mmstick
on 5 Aug 2019
Related issues
rask
·
3Comments
mathstuf
·
3Comments
JustAPerson
·
3Comments
tensorchen
·
3Comments
briansmith
·
3Comments
Most helpful comment
Encountered a similar issue where a workspace is split into multiple sub-crates, and each rely on specifying shared features of the main crate dependency. Something like this doesn't seem to work at all: