I’m trying to use a crate in no_std mode. The crate has a feature (enabled by default) that guards use of std lib, and which can be disabled to be used in no_std environments. Pretty standard stuff, no pun intended.
But it’s not working and I have no idea why. Cargo is doing something strange.
Cargo.toml has what seems to me to be the right thing from the documentation:
[dependencies.either] version = "1.5.0" default-features = false
cargo build -v seems to be defining the default and use_std features regardless:
Compiling either v1.5.0 Running `rustc --crate-name either /home/dan/.cargo/registry/src/github.com-1ecc6299db9ec823/either-1.5.0/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="use_std"' -C metadata=3ff95422768f7b18 -C extra-filename=-3ff95422768f7b18 --out-dir /home/dan/work/geek/rust/stm32rust/ws2812b/firmware/target/thumbv7m-none-eabi/debug/deps --target thumbv7m-none-eabi -L dependency=/home/dan/work/geek/rust/stm32rust/ws2812b/firmware/target/thumbv7m-none-eabi/debug/deps -L dependency=/home/dan/work/geek/rust/stm32rust/ws2812b/firmware/target/debug/deps --cap-lints allow -C link-arg=-Tlink.x -C linker=lld -Z linker-flavor=ld.lld` error[E0463]: can't find crate for `std` | = note: the `thumbv7m-none-eabi` target may not be installed
rustc command without the
--cfg 'feature="default"' --cfg 'feature="use_std"' args works and produces libs in the target directory (but cargo build wants to rebuild it on next invocation because of the difference, of course).
It doesn’t seem to be anything like a nested dependency; as far as I can tell nothing else is pulling in
either, and the build proceeds entirely without Either (to compile failures in my code) if I leave the stanza above out of Cargo.toml.
This is with
rustc 1.27.0-nightly (7360d6dd6 2018-04-15) for the
Some more details here: https://github.com/bluss/either/issues/23 but I’m now doubtful it’s the fault of the either crate specifically.