Open MarkSwanson opened 3 years ago
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 https://github.com/rust-lang/cargo/issues/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:
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 :)
I think this is somewhat a duplicate of #4463, which is unfortunately not easy to resolve.
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.
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.
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?
Problem 'cargo build --verbose' seems to indicate that rustc is compiling for the wrong target.
Steps
std
is required byvoid
because it does not declare#![no_std]
Partial Workaround
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 (e931e4796 2021-05-24)