Tbh I was really surprised that separateDebugInfo mangled my rustflags. I feel like adding debug flags should be a separate option and it should be up to me to set up any debug flags I want. What if I want separate debug info, but only for line tables?

Ideally if I wanted nix to set up debug flags for me I would write something like:

enableDebugInfo = true;
separateDebugInfo = true;

Though this is a breaking change so maybe we could explicitly disable debug flags instead:

enableDebugInfo = false;
separateDebugInfo = true;

Either way though we shouldn't override RUSTFLAGS.

Instead use CARGO_BUILD_RUSTFLAGS which merges rustflags.

Is this documented somewhere? To me the documentation implies they're aliases for each other.

Is this documented somewhere? To me the documentation implies they're aliases for each other.

It's not documented as such at all, but that's how it works. So it's unclear whether that's intentional or not.

There are four mutually exclusive sources of extra flags. They are checked in order, with the first one being used:

• CARGO_ENCODED_RUSTFLAGS environment variable.
• RUSTFLAGS environment variable.
• All matching target..rustflags and target..rustflags config entries joined together.
• build.rustflags config value.

Actually, I guess this sort of implies that CARGO_BUILD_RUSTFLAGS is not one of the mutually exclusive ways to specify rustflags.

This will work on cargo based rust projects (which are by far the majority), but will (AFAICT) not work for meson which can also compile rust (e.g. mesa's rusticl).

This comment implies it won't even work for Cargo.

Have you confirmed that (proper, with source locations etc.) debug info is actually generated with this change, and that CARGO_BUILD_RUSTFLAGS isn't just ignored? I can't check myself until I have some free build capacity, probably later today or tomorrow.

What we really need here, for this and some other Rust flags problems in Nixpkgs, is a compiler wrapper for Rust, just like we have for C. All we can do until we have that is try to paper over the cracks. So far, nobody has stepped up to do that.

(cc @yu-re-ka)

Yes, I've been using this env var for a long time in a number of projects, typically to enable --cfg flags without which these rust projects would not compile under Nix. It's definitely not ignored and it merges fine with existing rustflags.

A rustc wrapper would also work, but we wouldn't want to override user defined RUSTC_WRAPPERs either.

Yes, I've been using this env var for a long time in a number of projects, typically to enable --cfg flags without which these rust projects would not compile under Nix. It's definitely not ignored and it merges fine with existing rustflags.

Okay. Is the Cargo comment wrong, then, or am I misreading it?

A rustc wrapper would also work, but we wouldn't want to override user defined RUSTC_WRAPPERs either.

RUSTC_WRAPPER wouldn't solve our problem anyway, since it's Cargo-specific. We'd do what we do for the C compiler, which is to just make the rustc executable our wrapped rustc.

I can't find where this is implemented but there's a unit test covering this exact scenario: https://github.com/rust-lang/cargo/blob/a275529de24d893a9a6090f1d521822589e22a14/tests/testsuite/cargo_config/mod.rs#L294-L324

Edit: Sorry, one test above. Typing this from my phone.

This will work on cargo based rust projects (which are by far the majority), but will (AFAICT) not work for meson which can also compile rust (e.g. mesa's rusticl).

Tbh it seems weird to me that this one flag is supposed to just enable debug symbols for all kinds of build systems. Imo this really should be up to individual builders like buildRustPackage to implement.

I think all this flag should really do is run strip on the outputs and move debug symbols into its own file.

Imo this really should be up to individual builders like buildRustPackage to implement.

Then we'd have to separately implement the same thing for Cargo, Meson, the kernel, who knows what else?

The solution, again, is a wrapper, which would only need to be implemented once per compiler, not once per build system.

Then we'd have to separately implement the same thing for Cargo, Meson, the kernel, who knows what else?

A wrapper or a builder setting these, whatever makes the most sense and avoids setting these globally. Otherwise we'll eventually be setting flags for dozens of other build systems that are irrelevant to what you're actually building. I think the same goes for CC flags which could probably go to the cc wrapper as well.

Would it make more sense to set CARGO_PROFILE_RELEASE_DEBUG=full here instead?