-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Description
I've got a couple of projects (example) that are workspaces with a root crate and another member in an ffi
subdirectory. The ffi member has an ffi-headers
feature that uses cbindgen to generate C/C++ headers.
I expect to be able to run cargo build --release --all --all-features
and have all crates in the workspace built with all their features. This was working in Rust 1.25.0, I was able to run that command and see C/C++ headers get generated.
I upgraded to the Rust 1.26.0 release and now the above command no longer generates headers, it's as if the feature in the ffi crate is being ignored (the issue title may be a little inaccurate, I haven't verified this is what's actually happening). If I run cargo +1.25.0 build --release --all --all-features
, everything works as expected.
This might be related to #5362 and #5364, but they're more about --package
than --all
so I thought I'd file a new issue. If I run cargo +nightly build --release --all --all-features
, that doesn't work, but cargo +nightly build --release --all --all-features -Z package-features
does.
My current version of cargo is:
> cargo --version
cargo 1.26.0 (0e7c5a931 2018-04-06)
Running with the 1.25.0 toolchain:
> cargo +1.25.0 --version
cargo 0.26.0 (41480f5cc 2018-02-26)
Running with nightly:
> cargo +nightly --version
cargo 1.27.0-nightly (9e53ac6e6 2018-05-07)
Activity
Fix building Rust libraries with C++ headers using Rust 1.26.0
Fix building Rust libraries with C++ headers using Rust 1.26.0
alexcrichton commentedon May 17, 2018
Thanks for the report! Would it be possible to minimize this a bit perhaps to be easier to investigate?
@ehuss you may also be interested in this issue
Ortham commentedon May 20, 2018
Yes, I've uploaded a minimal example repository here. Running it (with cargo versions unchanged from what I gave above):
Copy `--all-features` request to all workspace members
--all-features
request to all workspace members #5556alexcrichton commentedon May 21, 2018
Ok thanks for the reduction! I can indeed reproduce this locally now. I've bisected this regression to 7de30dd (part of #5012, cc @infinity0)
I believe this should be fixed in #5556
infinity0 commentedon May 23, 2018
Sorry about that, thanks for catching. In general I think it's an anti-pattern to have enums with options like
{ AllSettings: {records}, Default, Preset1, Preset2 }
etc, I've seen far too much of this in various rust code. It would be better to have a single{records}
type with functions calleddefault()
preset1()
etc that return presets, with equality defined so one can still match against the presets if needed.Copy `--all-features` request to all workspace members
Ortham commentedon May 25, 2018
I just pulled and built 22c0f22 and can confirm it doesn't have the issue, thanks!