Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't pass --features from dev-dependencies to dependencies #4664

Closed
valarauca opened this issue Oct 27, 2017 · 10 comments
Closed

Don't pass --features from dev-dependencies to dependencies #4664

valarauca opened this issue Oct 27, 2017 · 10 comments

Comments

@valarauca
Copy link

@valarauca valarauca commented Oct 27, 2017

Working on a smallish project.

The main reason this came up was nom. Which has a feature flag that gates its new errors linky. If I include a dependency my whole build breaks as a dev-dependency is building nom with verbose errors.

@roblabla
Copy link
Contributor

@roblabla roblabla commented Nov 10, 2017

I have a similar issue, but with bindgen as a build-dependencies and libc as a dependencies in a nostd project.

Basically, bindgen depends (eventually) on libc (compiled with the default features, and so requires std). I'm building libc with nostd (my project is meant to be ran on a custom target with no std support), but it fails, saying it cannot find the crate std. If we turn on the verbosity of cargo, we can clearly see the use_std feature being passed to libc. Here's what I have : https://gist.github.com/anonymous/a42cc000486d5551d3849f3517d4b3a7

@radix
Copy link

@radix radix commented Dec 29, 2017

I have this problem too, working with serde in project with optional std support: https://github.com/radix/uom/blob/serde/Cargo.toml

If I'm building this uom branch with cargo build --features f32,serde --no-default-features, it still builds serde with std support. This is because the serde_json dependency in dev-dependencies depends on serde with default features. This is strange, because serde_json isn't even being built!

Shouldn't this be a bug instead of a feature-request?

@radix
Copy link

@radix radix commented Dec 29, 2017

btw this seems related to, or maybe the same as #4361

@roblabla
Copy link
Contributor

@roblabla roblabla commented Dec 29, 2017

it's related yeah. 4361 is about build-deps, we're about dev-deps, but a fix for one should probably fix the other.

@Eh2406
Copy link
Contributor

@Eh2406 Eh2406 commented Mar 26, 2018

This appears to be related to #2589

@mbrubeck
Copy link
Contributor

@mbrubeck mbrubeck commented Aug 23, 2018

Also duplicated by #4866.

@tarcieri
Copy link

@tarcieri tarcieri commented Jan 27, 2019

#2589 and #4866 appear to be the same as this issue to me.

Of these three, I prefer the write up in #4866

@dwijnand
Copy link
Member

@dwijnand dwijnand commented Feb 11, 2019

Duplicate of #4866

@dwijnand dwijnand marked this as a duplicate of #4866 Feb 11, 2019
@dwijnand dwijnand closed this Feb 11, 2019
@Nemo157
Copy link
Member

@Nemo157 Nemo157 commented Feb 12, 2019

#4866 is referring to build-dependencies in its OP, despite the title saying dev-dependencies. #2589 and #4866 are duplicates about build-dependencies features affecting dependencies always, while this is in relation to features from dev-dependencies affecting cargo build in a crate (or also when included as a path dependency of another crate when in a workspace). It's a bit different in that dev-dependencies should affect (public) dependencies features when running cargo test, as the dependency used in the tests needs to match the dependency used in the build.

@dwijnand dwijnand reopened this Feb 12, 2019
dtolnay added a commit to serde-rs/json that referenced this issue Aug 17, 2019
Our dev-dependency on trybuild enables serde's "derive" feature, which
we don't want affecting `cargo build`.
@ehuss ehuss self-assigned this Dec 6, 2019
@ehuss
Copy link
Contributor

@ehuss ehuss commented Feb 24, 2020

Non-unification of dev-dependency features has been implemented and is available as a nightly-only feature on the latest nightly 2020-02-23. See the tracking issue at #7916.

If people following this issue could try it out, and leave your feedback on the tracking issue (#7916), I would appreciate it. Particularly we'd like to know if it helps your project, does it cause any breakage, and is it a problem that binaries are still unified with cargo test?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants