-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Tracking issue for -Z features=itarget #7914
Comments
Does this affect lockfiles too? As in: if this feature is enabled, will a lockfile on Windows look different from a lockfile on Linux? Or is it only affecting behaviour of the actual build? |
It does not affect |
This seems to work, at least for my scenario: [target.'cfg(macos)'.dependencies] [target.'cfg(windows)'.dependencies] Building with: But I'm still a bit confused about the proposed solution. This clearly feels like a bug in the current feature resolver, but this fix proposes that we specify a different resolver? Or is this just a temporary solution while this fix gets merged into the "original" resolver? |
@johanlindfors it seems to work for me. What platform are you targeting? What did you see that made you think it isn't working? One thing, Yes, there is a new resolver, it is not a "bug" per se in the current resolver. The dependency resolver still needs to resolve all platforms for a stable dependency graph. These features also need to be resolved for multiple targets independently (host and target). It may be possible to do it with the current resolver, but I think it would require a multi-pass solution, so I don't think there would be any benefit, and a lot of downsides. |
|
|
@johanlindfors Yes, |
@ehuss You are right, I was using the cfg(target_os = "macos") syntax but when copying the code into the comment on github I manually "shortened" it, thinking I was being smart, turns out, as usual, that was not the case! :) |
The crater run for this has finished: https://crater-reports.s3.amazonaws.com/pr-69560/index.html There are about 9 regressions, which is a bit more than I was hoping for:
|
I am not able to get this to work:
Anything wrong with the syntax? |
@benmarten See above. |
@ehuss [target.'cfg(target_os = "macos")'.dependencies.opencv]
version = "0.32.0"
default-features = false
features = ['opencv-4']
[target.'cfg(target_os = "linux")'.dependencies.opencv]
version = "0.32.0"
default-features = false
features = ['opencv-32'] rustup override set nightly
cargo +nightly build -Z features=itarget |
rust-lang/cargo#1197 has more information; once rust-lang/cargo#7914 goes stable we can drop this hack.
I'm getting a panic from cargo when enabling the
There are no target specific dependencies in the particular lib that is being compiled (node-replication) but there are a few libc dependencies in transitive crates that are declared i.e., like this:
|
@gz Which version are you using? Is this a project I can look at? If not, can you create a reproduction? Or maybe show the dependency tree and the relevant dependency declarations. Also, it looks like you are using a custom JSON target spec, can you include that, too? |
@ehuss I put a minimal example here https://github.com/gz/itarget-bug that triggers the panic for me. It seems the culprit is when I try to include the |
Fix -Zfeatures=itarget with certain host dependencies In some cases, `-Zfeatures=itarget` can panic because an entry is missing in the activation map. This happens because the way "for_host" was tracked when building the activation map. Previously "for_host" was only set when `-Zfeatures=host_dep` was specified. However, if you don't specify `host_dep`, then "for_host" was always false. This is a problem because `itarget` needs to also be able to detect if something is enabled for the host or target. If you have a proc-macro ("for_host"), and it has a dependency with a `[target]` specification that matched the host, then the activation map would fail to include it (because the "for_host" flag was not "sticky" and didn't get passed down). The solution is to always carry the "for_host" setting around while building the activation map. Only when inserting a feature into the map will it check if `opts.decouple_host_deps` is set. This allows it to handle the "for_host" setting correctly, even if the `host_dep` option isn't enabled. This was discovered at #7914 (comment) where a dependency on `hashbrown` would fail if you pass `--target something_not_unix` because it has a unix-only dependency for `libc`. (Sorry, long-winded explanation. Please ask if that is confusing.)
Thanks for the fix (and the feature, it simplifies my cargo dependencies quite a lot). I can compile my project now with |
This is a complete overhaul of the way platform-specific dependencies are handled. Based on my experimentation and reading the Cargo source code, I believe that this is now correct. Doing so also required feature graph construction to be updated, so the feature graph construction is ready for the new feature resolver, and is now platform-sensitive as well. The APIs for the feature graph are still to come, but making the data model be full-fidelity allows for both the current and new feature resolvers to be implemented. For more about the new feature resolver, see: * https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#features * rust-lang/cargo#7914 * rust-lang/cargo#7915 * rust-lang/cargo#7916
I'd love to get this on stable. Is this on the path to stabilization? |
Definitely agree this would be great to have, but in case this helps anybody, here's a description of how I got around not having this for |
Properly skips optional dependencies pending rust-lang/cargo#7914 More extensible for addition of new platforms
2525: Autoselect gfx (only works on nightly) r=ezpuzz a=CleanCut A better than #2522 attempt to autoselect the graphics backend BUT only works by using nightly with the command `cargo +nightly build -Zfeatures=itarget` until rust-lang/cargo#7914 becomes stable. Mostly just making this PR so it's easy to find the attempt later. ~I intend to make yet another attempt via intermediate crates that might work on stable.~ Nope, this really seems like the better approach, once rust-lang/cargo#7914 is stabilized, so I'll just wait. Co-authored-by: Nathan Stocks <[email protected]> Co-authored-by: Emory Petermann <[email protected]>
It does not seem possible to do [target.'cfg(not(windows))'.features]
default = ["openssl"] Is this correct? |
Took me quite some time to find out, that I need to set resolver = "2" in my root Cargo.toml to activate this. |
Is this the right place to ask about "feature" specific dependencies? [target.'cfg(features = "fltk")'.dependencies]
optional = true
# specific fltk git repos I want a library to expose GUI elements if those features are requested by the end user |
You can already do this by adding the dependency in the feature definition, right? [features]
my_feature = ["my_dependency"]
[dependencies]
my_dependency = { version = "1.0", optional = true } |
Sorry I was not clear enough, I mean to ONLY included it for the features derived. Similar to compiling with OS specific crates, but only if features are requested. If this is already possible I missed it. [dependencies]
# things the library needs
[dependencies.my_feature]
# stuff to include ONLY when they want the GUI aspect There seems like something like this should be possible to me, but it may not be. |
@Razican I think I misunderstood what I was doing, I think I untangled what I was trying to do... sorry for the clutter 😅 |
Implementation: #7820
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#features
Summary
-Z features=itarget
causes the feature resolver to ignore features for target-specific dependencies for targets that don't match the current compile target. For example:When building this example for a non-Windows platform, the
f2
feature will not be enabled.Unresolved issues
cargo metadata
The text was updated successfully, but these errors were encountered: