Per-target profiles?

[SimonSapin]

#4817

This commit enables incremental compilation by default […] A profile.dev.incremental field is added to Cargo.toml to disable it on a per-project basis (in case of bugs).

I was hoping to use something like this:

[target.'cfg(windows)'.profile.dev]
incremental = false

to work around rust-lang/rust#47186, but looking at src/cargo/util/toml/mod.rs it seems that target.cfg sections can only be combined with dependencies, not other sections like profile.

Would it make sense to add support for this?

[SimonSapin]

I made a different work-around in Servo, have mach (the wrapper script that normally calls Cargo) set CARGO_INCREMENTAL=0 on Windows.

So there’s no pressing need to implement this as far as Servo is concerned. But maybe it could still be useful for other use cases.

[edwin0cheng]

In my use case , I need this feature to work around wasm32 related issue: rust-lang/rust#47643

[jedisct1]

LTO is currently broken on armv7, so I'd like such a feature to use fat LTO on x86_64 releases, but disable it elsewhere.

[kornelski]

I have a use-case for this too: I'd like to minimize code size for WASM targets, which means panic=abort, lto, opt-level=s, but for native targets I'd rather have different trade-offs.

[Geobert]

I have my own usecase for this: our company is using VS 2015 and we encounter this issue: briansmith/ring#1031

My workaround while waiting for the decision to update VS is to do:

[profile.release.package.ring]
opt-level = 0
debug-assertions = false

but it impacts Linux as well, and it's a pity

[danielhenrymantilla]

While waiting for an actual / true solution, I have posted a hacky workaround, that may suit some people / use-cases:

• https://users.rust-lang.org/t/how-to-modify-profile-release-only-for-a-target/48811/3?u=yandros

[vertexclique]

I eagerly need this, do we want to still do it?

[DanielJoyce]

Same here, specifically

[target."cfg(macos)".profile.dev]
split-debuginfo = "unpacked"

So it's only turned on for macs where it matters.

If cargo adds a config item, it really should work for everyone, even if ignored. Here the build is unhappy on Linux.

[rustonaut]

I have another wasm related use case our code runs some (in wasm) tests expressly slow if no optimizations are enabled.

In some of the more extreme cases setting opt-level=2 did lead to a speed up by a factor of over 10. But only for the wasm32 tests. For the x86_64 it's a net slow down in test speed by often around ~20%.

As a side note: This is not limited to wasm32 but appears also on android targets.

So being able to do:

[target.'cfg(any(target_arch="wasm32", target_os="android"))'.profile.dev]
opt-level = 2

[target.'cfg(any(target_arch="wasm32", target_os="android"))'.profile.test]
opt-level = 2

would be grate.

But there are some open questions:

• interactions with workspaces
• interaction with other scopes e.g. can we do target.<...>.profile.dev.package.foo
• given that it behaves like a profile directive shouldn't it be profile.dev.target.<...>

[carrion256]

In the meantime i think you can use rustflags with the -C command like so:

rustflags = [ "-C", "opt-level=z", "-C", "codegen-units=1" ]

That should help