Allow specifying rustflags per profile

[Boscop]

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).

[emanuellima1]

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]

Any update on this issue? I found this very useful since for C/C++, we have CMake that can pass profile-specific compiler args to compilers. Thx

[inodentry]

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]

Lol. Any workaround available currently? Or do we have to wait for cargo to really update itself someday? (Not pushing, jus curious

[inodentry]

Well, not really, unless you consider manually setting RUSTFLAGS when 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_dylib crate 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]

The moment you add use bevy_dylib; or equivalently extern crate bevy_dylib the dylib will be linked in. If you don't add use bevy_dylib;, rustc won't add it as dependency at all. The linker is not free to omit dylibs in most cases.

[Rua]

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=y to be on whenever I'm doing a debug build. There doesn't seem to be any way to automate this currently.

[glandium]

A logical extension of this would be to allow per-package overrides of rustflags, and that would be immensely useful for Firefox.

[Crypto-Spartan]

+1, also interested in this

[zertyz]

+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]

+1 this would be really useful

[wait-how]

+1 this would be a really helpful feature

[torokati44]

This would also be nice for ruffle-rs/ruffle#5834, so RUSTFLAGS wouldn'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]

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]

@msdrigg you can always run mold -run cargo build to use mold with a debug build

[ehuss]

This is now implemented via #10217, see #10271 for the tracking issue. It should land in nightly later this week.

[Systemcluster]

How should profile-rustflags interact with the rustflags source order? Currently it seems to have the lowest precedence, e.g. target-cpu in a profile rustflag is ignored when it is set in any .cargo/config.

[Wyvern]

Instead of place cargo-features = ["profile-rustflags"] in all package cargo.toml files, is there a way to set it in global .cargo/config file?

[Wyvern]

It's better to add profile based rustflags override, in some cases we need specific profile to override flags in build section.

For example, when LTO profile need to override "-Cprefer-dynamic",

[profile.lto]
inherits = "release"
rustflags = [
"-Cprefer-dynamic=no",
"-Zvirtual-function-elimination",
]
lto=true

[build]
rustflags = [
"-Cprefer-dynamic",
"-Crpath",
]

as for now, this flag was ignored.

[elichai]

Is this feature any closer to stabilization?

[weihanglo]

For the progress of it, please see the tracking issue #10271 and other issue of Z-profile-rustflags Nightly: profile-rustflags .