Support for target-specific dependencies

[vlovich]

Describe the problem you are trying to solve
I want to provide a feature in my Crate that may have target-specific dependencies. In other words, I want to add a feature "f1" to my crate in my [features] section that depends on glommio on Linux (it's a Linux-only crate). On other platforms I may have a different dependency set. #1197/#7914 seem to be more about conditionally enabling features of an upstream package upstream rather than conditionally including the package altogether.

The ability to conditionally include a dependency for a feature based on the platform.

Describe the solution you'd like
Conditionally specifying the dependencies for a feature seems like the right approach perhaps? I don't really know Cargo well enough.

[features]
default = ["f1"]
f1 = ["memmap"]

[target.'cfg(linux)'.features]
f1 = ["glommio"] # Add glommio to the dependency set for f1 on Linux

[dependencies]
memmap = { "0.7.0", optional = true }
glommio = { "0.2.0-alpha", optional = true } # Would only get built on Linux

Notes
Apologies if there's already an issue tracking this or some other idiomatic way to express this. I've tried looking but couldn't find anything.

[ehuss]

I believe you can express it as a target-specific dependency like this:

[dependencies]
memmap = { "0.7.0", optional = true }

[target.'cfg(unix)'.dependencies]
glommio = { "0.2.0-alpha", optional = true }

[features]
f1 = ["memmap", "glommio"]

[roccodev]

I can see this be trivial when #1197 gets stabilized (currently available in nightly: tracking issue #7914).

[vlovich]

@ehuss Hmm... does that example work on all platforms as expected? Specifically, in the original problem statement I had default = ["f1"] whereas in your snippet that's missing. In other words is the downstream user also expected to properly conditionally enable the f1 feature for that platform?.

I'm an all around rust n00b so apologies for the silly questions. I would have guessed Cargo builds up the dependency resolution info from the [dependencies] section & dependencies declared by a feature but missing the dependency info would be an error. Does the new dependency resolution in #1197 do magic to record that there was dependency information provided for a specific configuration to avoid the error but elides the crate? I'm curious what happens if I do something silly like:

[dependencies]
memmap = { "0.7.0", optional = true }

[target.'cfg(unix)'.dependencies]
glommio = { "0.2.0-alpha", optional = true }

[target.'cfg(windows)'.dependencies]
glommio = { "0.4", optional = true }  // This version number is bogus

[features]
default = ["f1"]
f1 = ["memmap", "glommio"]

Where the dependency info for glommio is broken for Windows (currently the max version is 0.2). Does this mean that the build will only fail when I try to build on Windows but succeed otherwise? Just trying to build a mental model of how this works.

[ehuss]

You can add default, it should work.

You cannot have invalid versions in a dependency, even if it is for another target. Cargo builds the resolve graph ignoring the target specification (it resolves all of them at the same time).

[vlovich]

Ok, so this is indeed a dupe of #7914. Sorry for the noise.