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 of [target.'cfg(...)'.dependencies] and [target.'cfg(not(...))'.dependencies] are merged when used in a workspace #12387

Closed
oblique opened this issue Jul 21, 2023 · 1 comment
Labels
C-bug Category: bug S-triage Status: This issue is waiting on initial triage.

Comments

@oblique
Copy link

oblique commented Jul 21, 2023

Problem

I have project in a workspace that has something like the following Cargo.toml:

[package]
name = "bug"
version = "0.1.0"
edition = "2021"

[dependencies]

[target.'cfg(target_arch = "wasm32")'.dependencies]
tokio = { version = "1", features = ["sync"] }

[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
tokio = { version = "1", features = ["net"] }

When I was running cargo build --target wasm32-unknown-unknown then Tokio's net feature got enabled too and I was getting compilation errors because of mio crate.

This is an issue only if the project is in a workspace.

Steps

  1. git clone https://github.com/oblique/cargo-features-bug
  2. cargo build --target wasm32-unknown-unknown

Possible Solution(s)

No response

Notes

I created a minimal example: https://github.com/oblique/cargo-features-bug

Version

cargo 1.71.0 (cfd3bbd8f 2023-06-08)
release: 1.71.0
commit-hash: cfd3bbd8fe4fd92074dfad04b7eb9a923646839f
commit-date: 2023-06-08
host: x86_64-unknown-linux-gnu
libgit2: 1.6.4 (sys:0.17.1 vendored)
libcurl: 8.0.1-DEV (sys:0.4.61+curl-8.0.1 vendored ssl:OpenSSL/1.1.1t)
ssl: OpenSSL 1.1.1t  7 Feb 2023
os: Arch Linux Rolling Release [64-bit]
@oblique oblique added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Jul 21, 2023
@oblique
Copy link
Author

oblique commented Jul 21, 2023

Worked after adding the following:

[workspace]
resolver = "2"

I didn't know that resolver needs to be explicitly set in case of a workspace.
I'm closing this.

@oblique oblique closed this as completed Jul 21, 2023
bors added a commit that referenced this issue Jul 26, 2023
docs: raise awareness of resolver used inside workspace

Workspaces by default use the resolver in version 1. It's been some time already since the 2021 edition which made version 2 a default for alone packages, but yet most of the projects that make a use of the workspaces still depends on  an old resolver.

By being explicit about the resolver tag inside the workspace we can lower the usage of older resolver for the new projects.

This can raise the awareness of this behavior and prevent issues like #12387. I also wasn't aware of this behavior before while not being so new to Rust, and we have the resolver 2 for good reasons, so I think we should be more explicit about it in the documentation.
When someone looks for the 'how to make cargo workspace' answers, he's unlikely to get to the `Dependency Resolution` section at the same time, he'll likely just copy paste the workspace example from the `Workspaces` and call it a day, yet extending the usage of an old resolver and not benefiting from the new one.
nekowinston added a commit to catppuccin/toolbox that referenced this issue Jul 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

1 participant