per-package-target unifies features which can conflict with other targets

[MarkSwanson]

Problem
'cargo build --verbose' seems to indicate that rustc is compiling for the wrong target.

Steps

1. git clone https://github.com/MarkSwanson/build-failed1.git
2. cargo build --verbose
   3.Note the rustc error compiling the void (1.0.2) crate
   ...
   std is required by void because it does not declare #![no_std]

Partial Workaround

1. cd into each workspace package individually and 'cargo build'. For some reason cargo works perfectly this way.
   However, this doesn't work with vscode.
2. remove "rpi4" from Cargo.toml workspace members.
   Sadly then I can't build the raspberry pi 4 target.

Notes
It seems positive that all build targets (x86, thumbv7em-none-eabihf, thumbv7m-none-eabi, armv7-unknown-linux-musleabihf) work perfectly if I run 'cargo build' from their respective workspace package dirs. (slight graph miscalculation when compiled from the root of the workspace?)

I note that the void crate is designed to work with std and no-std. However, the rustc error might indicate that rustc needs to have a slightly more robust check to detect how the void crate uses cfg or cfg_attr to support both environments?

Output of cargo version:
cargo 1.54.0-nightly (e931e47 2021-05-24)

[Ekleog]

Hmmm… Haven't investigated the linked code much yet, but based on the description I'd guess this is a side-effect of the second checkbox at #9406: void probably has a std feature, one of the crates of the workspace depends on it with the std feature, and the other one depends on it as no_std; thus leading to a problem.

Based on an overall look at the code, I'd think:

• defmt-gdb transitively depends on void while requiring it to be no_std
• rpi4 depends on nrf24l01 -> spidev -> nix 0.6.0 (that's an old version, probably bumping it somewhere along the dependency tree would be beneficial) -> void with the std feature

So I'll triage it on the tracking issue as one instance of the second checkbox, thank you for having filed this and linked there :)

[ehuss]

I think this is somewhat a duplicate of #4463, which is unfortunately not easy to resolve.

[FrankvdStam]

I think I ran into a similar issue before when I was trying this feature. What ended up working for me was making sure I specify a target for each crate, even if it should be the default. So forced-target = "x86_64-pc-windows-msvc" in Cargo.toml with cargo-features = ["per-package-target"] at the top.

[tmplt]

I also hit this. I have a host application that depends on num-traits's std feature-set, and a firmware crate that depends on its no-std feature-set. See https://github.com/tmplt/cargo-rtic-trace/tree/demo/per-package-target. cargo-rtic-trace/ is the host application. examples/ contains the firmware.

[MarkSwanson]

Fwiw I worked around this by using cargo-make. Example:

[config]
skip_core_tasks = true

[tasks.default]
command = ""
args = []
alias = "custom-default"

[tasks.custom-default]
dependencies = [ "build-rpi4", "build-stm32f103", "build-xtask", "build-defmt-gdb", "build-common" ]

# rustup target add thumbv7m-none-eabi
[tasks.build-stm32f103]
command = "cargo"
args = ["build", "--manifest-path", "stmf103/Cargo.toml"]
dependencies = [
    "readme"
]

...
However, I lose Cargo's workspace ability to ensure dependencies are the same between directories/packages.

I could also make each of these their own separate git repo/crate. But I'd still lose the workspace ability to ensure dependencies are the same.

I found that Cargo has resolver = "2" (a new resolver that includes more things in the dependency/build graph for each package) but it didn't work.

It seems that Cargo is trying hard to be considerate to the developer and ensure that only the minimal set of packages are compiled per workspace member. I appreciate that, but I wonder if we also need an option that says - just create a separate full build graph for each member. I realize this would increase initial compile times, but it would always work. Crazy?

[andreasWallner]

per-package-target would make our embedded / host software / unittest builds quite a bit simpler, so I had a look at this.

I set up a simpler repro (no dependencies, only 3 creates) that shows the issue happening: https://github.com/andreasWallner/per-pkg-target-feature-resolution-repro

With that I had a look at the cargo resolver, and I think I have a fix: https://github.com/andreasWallner/cargo/tree/ppt_feature_resolution

I'm not entirely happy with the checks for whether "--feature" was passed, and I did not learn enough about the codebase to understand whether I'm slightly breaking stuff here or not... But I'd be happy to spend some more time on this if someone would be willing to have a look and provide some feedback. (Tests for this are on the way ;-) )

Maybe interesting for anyone who needs this: The nightly feature-unification setting as "package" also works around the issue (see #3692)