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

[lima-emanuel]

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.