Use a single profile set per workspace #3249
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
matklad
force-pushed
the
workspace-profiles
branch
from
88cc5aa to
151f12f
Compare
|
@bors: r+ Thanks! Seems reasonable to me in terms of backcompat story |
|
📌 Commit 151f12f has been approved by |
Use a single profile set per workspace This aims to close #3206. I have not figured out how to do this 100% backward compatibly, that's why I want to discuss this separately, although a related PR (#3221) is already in flight. The problem is this: suppose that you have a workspace with two members, A and B and that A includes a profiles section and B does not. Now, mentally `cd` inside B and run `cargo build`. Today, Cargo will use a default profile. We want it to use a profile from A. So here the silent behavior switch will inevitably occur :( Looks like we can't detect this situation. So this PR just switches the behavior to always use root profiles, and to print a warning if a non-root package specifies profiles. Feel free to reuse it in any form for #3221 if that's convenient!
|
Should this be tagged with relnotes? |
|
☀️ Test successful - cargo-cross-linux, cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64 |
|
Why can't workspace members override workspace profiles? (My project reiled on different profiles in different crates and now it's broken) |
|
@alexbool that's a possible extension we could implement, yes, but wasn't the intention of workspaces. It leads to surprising behavior currently when you switch between members and everything is recompiled due to profile changes. |
|
@alexcrichton I tend to agree with you, but what makes me sad is that it could be done with no breakage... |
|
It might be best to open up a new issue for this, but I've been working in a workspace that includes both a server-side crate, and a client-side crate using wasm. I'd like to have the wasm-based crate to produce the smallest possible binary using This seems like a valid use-case to allow per-workspace-member profile overrides, which I believe isn't possible yet: |
|
@JeanMertz You can use Profile Overrides to set the profile per-package. That will only apply to a single package (not dependencies). If you want to toggle between settings that apply to the entire crate graph, you can do tricks with Config Profiles and environment variables (or swapping |
|
LTO is one of the recommended options for WASM and doesn't work in overrides right now |
This aims to close #3206.
I have not figured out how to do this 100% backward compatibly, that's why I want to discuss this separately, although a related PR (#3221) is already in flight.
The problem is this: suppose that you have a workspace with two members, A and B and that A includes a profiles section and B does not. Now, mentally
cdinside B and runcargo build. Today, Cargo will use a default profile. We want it to use a profile from A. So here the silent behavior switch will inevitably occur :( Looks like we can't detect this situation.So this PR just switches the behavior to always use root profiles, and to print a warning if a non-root package specifies profiles. Feel free to reuse it in any form for #3221 if that's convenient!