Skip to content

Commit f2075e1

Browse files
committed
fix(drawbacks): Put more emphasis on relationship with --workspace, mutually exclusive features is just an example
1 parent e3fa072 commit f2075e1

File tree

1 file changed

+7
-8
lines changed

1 file changed

+7
-8
lines changed

text/3692-feature-unification.md

Lines changed: 7 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -103,14 +103,13 @@ Specify which packages participate in [feature unification](https://doc.rust-lan
103103

104104
This increases entropy within Cargo and the universe at large.
105105

106-
If someone enables mutually exclusive features in different packages, then `workspace` unification will fail.
107-
Officially, features are supposed to be additive, making mutually exclusive features officially unsupported.
108-
Instead, effort should be put towards [official mutually exclusive globals](https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618).
109-
110-
Some features cannot be enabled in some packages, like a `no_std` package not wanting `std` features.
111-
These workspaces will not be able to use `workspace` unification.
112-
For now, unifying for the `"workspace"` is primarily targeted at single-application workspaces.
113-
The other config fields can always be used instead.
106+
As `workspace` unifcation builds dependencies the same way as `--workspace`, it has the same drawbacks as `--workspace`, including
107+
- If a build would fail with `--workspace`, then it will fail with `workspace` unification as well.
108+
- For example, if two packages in a workspace enable mutually exclusive features, builds will fail with both `--workspace` and `workspace` unification.
109+
Officially, features are supposed to be additive, making mutually exclusive features officially unsupported.
110+
Instead, effort should be put towards [official mutually exclusive globals](https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618).
111+
- If `--workspace` would produce an invalid binary for your requirements, then it will do so with `workspace` unification as well.
112+
- For example, if you have regular packages and a `no_std` package in the same workspace, the `no_std` package may end up with dependnencies built with `std` features.
114113

115114
# Rationale and alternatives
116115
[rationale-and-alternatives]: #rationale-and-alternatives

0 commit comments

Comments
 (0)