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

Features don't interact well with workspace crates #82

Open
iliekturtles opened this issue Apr 25, 2018 · 1 comment
Open

Features don't interact well with workspace crates #82

iliekturtles opened this issue Apr 25, 2018 · 1 comment

Comments

@iliekturtles
Copy link
Owner

See https://internals.rust-lang.org/t/help-us-test-the-breaking-bug-fix-to-cargo-features/7317 and rust-lang/cargo#5364. Also see the current .travis.yml where cargo test is run once for uom and once for feature_check.

Currently if you use cargo --test --all workspace crates are compiled with their default features (--features does not affect them) and link against the root package that is built with the specified features including dev-dependencies. If you use cargo test --manifest-path ... to manually run test for a workspace crate that references the root package then the root package is recompiled without dev-dependencies.

Ideally the uom CI build scripts should run both uom and feature_check tests and only compile uom once.

A possible short term fix is to have feature_check use the same feature set in the cargo build invocation so those build artifacts can be reused.

@iliekturtles iliekturtles added this to the v1.0.0 milestone Jun 29, 2019
@iliekturtles
Copy link
Owner Author

Currently cargo test --all --features ... still does not pass features to all workspace crates. Oddly workspace crates still use the version compiled with features. Currently feature_check is reusing the previously compiled uom but edition_check isn't because --manifest-path needs to be used as the crate is not part of the workspace. Once the minimum required rustc is bumped to 1.31.0 (Rust 2018 edition) then edition_check can be added back into the workspace and this issue should be reviewed again.

@iliekturtles iliekturtles removed this from the v1.0.0 milestone Jul 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant