Platform specific dependencies failing to resolve dependencies with different path

[Nazariglez]

Problem
Adding different dependencies using the same name and different path for different platforms display this error:
Dependency 'backend' has different source paths depending on the build target. Each dependency must have a single canonical source path irrespective of build target.

The book says that this is allowed here: https://doc.rust-lang.org/1.32.0/cargo/reference/specifying-dependencies.html#platform-specific-dependencies

[target.'cfg(target_arch = "x86")'.dependencies]
native = { path = "native/i686" }

[target.'cfg(target_arch = "x86_64")'.dependencies]
native = { path = "native/x86_64" }

This is my code:

[target.'cfg(target_arch = "wasm32")'.dependencies]
backend = { path = "./web-backend", package = "web-backend"}

[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
backend = { path = "./native-backend", package = "native-backend"}

[workspace]
members = [
    "web-backend",
    "native-backend"
]

I think that this should compile and use inside the code web-backend as backend for wasm32 and native-backend as backend for different targets.

Steps
I made a simple test project: https://github.com/Nazariglez/cargo-dep-bug

Possible Solution(s)
Not sure how to fix this, or what is the solution, but maybe is related to this other (closed) issue: #5345

Notes
Output of cargo version: cargo 1.40.0 (bc8e4c8 2019-11-22)
Output of rustc --version: rustc 1.40.0 (73528e339 2019-12-16)
OS: MacOS Mojave 10.14.6
Target: wasm32-unknown-unknown and default
Channel: Stable and nightly

[ehuss]

Hmm, at a minimum the documentation is wrong.

I'm not sure what the feasibility is of supporting that use case. It can be tricky to ensure that different target expressions are mutually exclusive. For example, cfg(target_os="windows") and cfg(target_arch="x86_64") can both be true, so Cargo would need to defer the duplication check until very late.

Maybe @Eh2406 can comment on the feasibility of the resolver supporting that. But I suspect overall this would be hard to support reliably.

[Eh2406]

@Nazariglez Thanks for such a high quality report!

My main question is why do the docs say that!? Did it ever work!? Git blame thinks it goes back to 4d590f9

The mutual exclusivity also needs to be global, the question is not the straightforward "does this computer have both of these flags" but the much harder "is there a computer that has both of these flags".

[paulirotta]

We can guarantee exclusive if the not structure is baked into any future fix. Moving from

(this fails)

[target.'cfg(target_arch = "x86_64")'.dependencies]
quicksilver = {git = "https://github.com/paulirotta/quicksilver.git", branch="image-fix-test"}

[target.'cfg(not(target_arch = "x86_64"))'.dependencies]
quicksilver = {git = "https://github.com/paulirotta/quicksilver.git", branch="v3-gl3-i8u8-fix"}

to something along the lines of

[target.'cfg(target_arch = "x86_64")'.dependencies]
quicksilver = {git = "https://github.com/paulirotta/quicksilver.git", branch="image-fix-test"}
[else]
quicksilver = {git = "https://github.com/paulirotta/quicksilver.git", branch="v3-gl3-i8u8-fix"}

As there seems to be no orthodox solution, I'll just continue to ugly through it.

[dalcde]

I think it would make sense to allow this and error only when there is a conflict for the specific target you are actually building.

[azerupi]

The Cargo book still gives this as a valid example: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#platform-specific-dependencies

In the meantime we have used this simple workaround:

Cargo.toml

# Compile with the simulator on Windows and Unix (dev machines)
[target.'cfg(any(windows, unix))'.dependencies]
simulator = { path = "../simulator" }

# Compile with real remote bindings on other targets
[target.'cfg(not(any(windows, unix)))'.dependencies]
real = { path = "../real" }

lib.rs

#[cfg(not(any(windows, unix)))]
pub use real as remote;
#[cfg(any(windows, unix))]
pub use simulator as remote;

Maybe this might be a good enough solution to propose in the documentation?

[joshmarinacci]

I just ran into this issue as well. It should be updated to say that you have to name each crate differently and then import them conditionally.