cargo-pgo ignores all rustflags defined in config.toml file, how to pass custom rustflags to pgo build?

[Wyvern]

Looks like cargo pgo [optimize] build ignores rustflags in config.toml file, is there a way to pass it to PGO subcommand?

[Kobzol]

Hi, this has been already reported here. Could you just pass these flags manually in RUSTFLAGS? It's not trivial to append rustflags in cargo pgo without overriding .cargo/config.toml.

[Wyvern]

But my rustflags=[...] in config.toml is very long, pass it through env var is NOT convenient. Furthermore, there is profile based rustflags which can switch between different profiles. Put everything in RUSTFLAGS is not a reasonable approach.

[Kobzol]

I see. I did consult this with the Cargo developers and we didn't find a much better way. So perhaps this will require cargo-pgo to parse config.toml to make this work.

Out of curiosity, how do you use per-profile rustflags? Didn't you mean per-target?

[Wyvern]

Cargo has already supported [unstable.profile-rustflags = true] option.
rust-lang/cargo#10271
https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-rustflags-option

[Kobzol]

Oh, it's unstable! Cool.

I think that I have an idea how this could be done. I also battled with overriding rustflags in https://github.com/Kobzol/cargo-remark, and there the solution was to use cargo build --config build.rustflags=[] (see discussion here). I will try it.

[Kobzol]

Okay, it seems to work! But the --config parameter is unstable :( You can try

$ cargo install --git https://github.com/kobzol/cargo-pgo --branch append-to-rustflags

If it works for you.

[Kobzol]

Oh, my bad, it's not actually unstable (it was stabilized in 1.63.0). I was just testing with 1.56.1, which is the minimum supported version by cargo-pgo. So I will be able to just check the Rust version and use RUSTFLAGS or --config based on it, good! So please just confirm if this works for you.

[Wyvern]

And also [host.rustflags] detection when cargo's

[unstable]
host-config = true
target-applies-to-host = true

is applied.
IIRC, [host.rustflags] will override [build.rustflags].

[Wyvern]

Maybe the entire chain of rustflags should be {build, host, target.'cfg(all())', target.*, profile.*}.rustflags.

[Kobzol]

I don't think that it's in scope of cargo-pgo to reimplement the whole rustflags resolve logic from cargo, any it would break in the future anyway if Cargo does any changes. So for now, using build.rustflags seems like a reasonable compromise for me, in order to support perhaps the most common use-case, without overriding the flags.

Does it work for you?

[Wyvern]

Well, host.rustflags cover more areas than build.rustflags such as build.rs and macro optimization. If pgo subcommand only support build.rustflags, it's ok for now. But it's a burden for developers to have to duplicate the rustflags in both [host] and [build] sections. And currently, cargo already ignored build.rustflags when you use host.rustflags, so all cargo-* subcommand should follow this convention to align with cargo's behavior pattern.

So the better option is, [host] first if not fall back to [build] to read rustflags.

[Kobzol]

Where is host.rustflags documented? I only see build and target.<XYZ> here.