building workspaces can't use --features flag #5015
Comments
|
Yes right now |
alexcrichton
added
the
C-feature-request
|
Thank your report.Wish this feature can quick complete. I use two [[bin]] point some other needed feature.it is too low.but thank god this can good work. |
|
En..Can I push feature arguments with 'cargo build' pass to sub-creat?like my example. I think that looks very natural |
|
You should be able to do |
|
@SamPeng87: could you please test alexcrichton’s suggestion, so that the issue can perhaps be closed? |
|
Attempting to reference a feature in a member of a virtual manifest/workspace does not work (testing with Also, I'm not sure whether there's a good behaviour for these to all have, but if they're not going to apply when building from a virtual manifest then maybe they should warn/error to inform the user? |
alexcrichton
added
the
A-diagnostics
|
See also #5364, that appears to cover most of the relevant behaviour and should hopefully close this. |
|
@alexcrichton Passing a feature flag works for crates in a workspace, but how can one disable a default feature flag? |
|
There is no way to selectively disable on default feature, rather you need to turn them all off with |
|
It is possible to use the |
|
Ah no, not currently, it has to be directed at a package not a workspace |
@alexcrichton this isn't working for me in https://github.com/servo/webxr/ (try This bug is particularly annoying because this forces me to build from a subfolder, but cargo sets the error message root as the workspace root, so i can't click on the errors to have them open in my editor |
|
Ah, you can use |
|
I think having |
|
Is there any ongoing work for |
Before this change the ledger code was compiled _without_ `no_std` to the Wasm target. This did not cause problems yet since we did not use any `std` code. However, in the future we would have run into issues if we inadvertently used `std` code. The reason why `no_std` was not enabled was that the `--no-default-features` flag was not respected in `tool/build-ledger-wasm` because of rust-lang/cargo#5015.
No idea what changed here, but for some reason Cargo does not allow to use "--features" with virtual crates now. However, it has no issues with it once we're in "themis" crate subdirectory and ask to document all crates in the workspace anyway. Apparently, "--features" was not supposed to work with workspaces in the first place [1], but I have no clue it worked before. [1]: rust-lang/cargo#5015
* Fix clippy::needless-doctest-main
Recently released Clippy 1.40 ships with this lint enabled by default.
Since we run with "warnings as errors" policy, this lint causes build
failures which is not nice.
error: needless `fn main` in doctest
--> src/wrappers/themis/rust/libthemis-src/src/lib.rs:37:4
|
37 | //! fn main() {
| ^^^^^^^^^^^^
|
= note: `-D clippy::needless-doctest-main` implied by `-D warnings`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_doctest_main
error: aborting due to previous error
I wouldn't say that explicit main() here is needless and some people
share the same sentiment [1]. However, since this is top-level module
docs, we cannot disable this lint for this place specifically without
turning it off in the entire module. Okay, Clippy, you win.
[1]: rust-lang/rust-clippy#4858
* Fix Cargo with "--features"
No idea what changed here, but for some reason Cargo does not allow to
use "--features" with virtual crates now. However, it has no issues with
it once we're in "themis" crate subdirectory and ask to document all
crates in the workspace anyway.
Apparently, "--features" was not supposed to work with workspaces in the
first place [1], but I have no clue it worked before.
[1]: rust-lang/cargo#5015
|
I'm sure there's a few reasons why this doesn't work, but a naive attempt to use I feel like I'd expect a workspace to have effectively the union of the features of it's members. Members could even have the same features and they would be controlled as one. For example, in a workspace with: [workspace]
members = [
"foo",
"bar",
]I may have the following two manifests: # foo/Cargo.toml
[features]
default = ["a", "c"]
a = []
b = []
c = []
d = []# bar/Cargo.toml
[features]
default = ["a", "e"]
a = []
b = []
e = []
f = []Here I think I'd expect the following:
What am I missing? This seems somewhat straightforward. Could I take a stab at implementing this in cargo? |
|
I'm stuck on this one now too. Due to a different but related shortcoming I have But now one of the packages in the workspace has a nightly-only feature, and using I'm stuck. Any advice is appreciated. |
|
Isn't this a dupe of #4753 - can we close this one and continue the discussion there? |
|
@gilescope I tried collecting all the related (possibly duplicate) issues in https://internals.rust-lang.org/t/features-and-workspaces-request-for-meta-issue/11964 hoping to aggregate them. No responses as of yet however. |
i define feature in some sub-create
then,execute cargo
cargo build --features="develop"it can't work,only work in sub-create
defaultfeatures selectors.cargo build --no-default-features --allnot work tooIs it a Bug?
The text was updated successfully, but these errors were encountered: