Repository navigation
Allow specifying rustflags per profile #7878
Description
Related to #5777 but a separate issue:
Please allow specifying rustflags per profile.
It would be very useful for setting certain flags only in debug or release (or even custom profiles).
E.g. I have a workspace with multiple crates, plus one backend bin crate and one frontend wasm crate, and I want to set rustflags = ["-Ctarget-feature=+crt-static", "-Ctarget-cpu=haswell"] only for the backend and only for release builds!
Btw, when I just set rustflags = ["-Ctarget-feature=+crt-static", "-Ctarget-cpu=haswell"] in .cargo/config now, (even though rustc ignores these flags when building my wasm frontend), cargo always recompiles all deps when switching between building the backend and frontend sub-crates. Even though for the frontend, everything is compiled for the wasm target anyway, so the compiled deps are never shared between frontend and backend crates! (Probably avoidable / another issue.)
If it was possible to set rustflags per profile, together with profile-overrides it would be possible to avoid the unnecessary recompilation because I could set rustflags only for the backend and only for release builds, and in addition I could set other flags only for the frontend crate.
Also this would allow things like using the standard linker for release and lld for debug builds (to shorten linking time).
Activity
lima-emanuel commentedon Oct 5, 2020
Hello everyone. I would like to work on this issue because I need this functionality in Cargo for my research. The thing is, I don't have much experience in contributing to open source. Is any kind of mentoring available?
jerryc05 commentedon Nov 7, 2020
Any update on this issue? I found this very useful since for
C/C++, we haveCMakethat can pass profile-specific compiler args to compilers. Thxinodentry commentedon Nov 7, 2020
My new big reason for wanting this feature is the above linked issue bevyengine/bevy#791
Turning big frameworks like Bevy and Tokio into dylibs for development builds is a big compile time win.
jerryc05 commentedon Nov 9, 2020
Lol. Any workaround available currently? Or do we have to wait for
cargoto really update itself someday? (Not pushing, jus curiousinodentry commentedon Nov 10, 2020
Well, not really, unless you consider manually setting
RUSTFLAGSwhen building to be a valid workaround. I guess you could wrap cargo in an external script that sets the env var and calls cargo.For the dylib use case, bevy is providing another workaround: a dummy
bevy_dylibcrate which just reexports all of bevy, but builds only as a dylib. The main bevy crate selects it as an optional dependency behind a cargo feature (which can be selected based on profile).OFC, this is just for that use case. There are many other valuable use cases for setting rustflags per-profile (as described in the OP), and cargo should definitely support it.
bjorn3 commentedon Nov 10, 2020
The moment you add
use bevy_dylib;or equivalentlyextern crate bevy_dylibthe dylib will be linked in. If you don't adduse bevy_dylib;, rustc won't add it as dependency at all. The linker is not free to omit dylibs in most cases.Rua commentedon Jan 22, 2021
I'm interested in this feature. I compile debug builds with
opt-level = 1, but I still want to be able to do profiling so I need-C force-frame-pointers=yto be on whenever I'm doing a debug build. There doesn't seem to be any way to automate this currently.glandium commentedon Apr 28, 2021
A logical extension of this would be to allow per-package overrides of rustflags, and that would be immensely useful for Firefox.
Crypto-Spartan commentedon Jun 18, 2021
+1, also interested in this
zertyz commentedon Jun 30, 2021
+1 for this. It makes total sense to have this feature and I'm currently missing it -- want development builds to compile as fast as possible, but release builds to be as optimized as possible
aidnzz commentedon Aug 22, 2021
+1 this would be really useful
wait-how commentedon Dec 13, 2021
+1 this would be a really helpful feature
torokati44 commentedon Dec 13, 2021
This would also be nice for ruffle-rs/ruffle#5834, so
RUSTFLAGSwouldn't have to be set in two different places for the different builds, and also the build cache could be kept separate for them.msdrigg commentedon Dec 17, 2021
Now that mold is 1.0, I would like to link with mold in debug builds and use the standard linker in releases. This feature would help with this
Crypto-Spartan commentedon Dec 17, 2021
@msdrigg you can always run
mold -run cargo buildto use mold with a debug buildAuto merge of #10217 - zhamlin:feat/profile-rustflags, r=ehuss
ehuss commentedon Jan 10, 2022
This is now implemented via #10217, see #10271 for the tracking issue. It should land in nightly later this week.
Systemcluster commentedon Jun 6, 2022
How should
profile-rustflagsinteract with the rustflags source order? Currently it seems to have the lowest precedence, e.g.target-cpuin a profile rustflag is ignored when it is set in any.cargo/config.Wyvern commentedon Jul 12, 2022
Instead of place
cargo-features = ["profile-rustflags"]in all package cargo.toml files, is there a way to set it in global.cargo/configfile?Wyvern commentedon Oct 1, 2022
It's better to add profile based
rustflags override, in some cases we need specific profile to override flags inbuild section.For example, when
LTOprofile need to override"-Cprefer-dynamic",as for now, this flag was ignored.
elichai commentedon Aug 15, 2023
Is this feature any closer to stabilization?
weihanglo commentedon Aug 15, 2023
For the progress of it, please see the tracking issue #10271 and other issue of Z-profile-rustflagsNightly: profile-rustflags
.