can't specify lto in profile on specific packages

[sehz]

Problem

Cargo doesn't accept lto in profile as below:

[profile.release.package.fluvio-filter-test]
lto = true

Steps
This result in following error message:

$ cargo check
error: failed to parse manifest at `/home/ubuntu/fluvio/Cargo.toml`

Caused by:
  `lto` may not be specified in a `package` profile

$ cargo version
cargo 1.51.0 (43b129a20 2021-03-16)

[ehuss]

Thanks for the report! Can you say more about your use case? LTO only works for the final artifact, so it can't be set per-dependency. Is this maybe an executable in a workspace?

[M1cha]

library crates (like clap-rs) can enable LTO. If the toolchain does not support LTO the build is gonna fail even though the binary crate you're trying to build doesn't have that enabled.

[petrochenkov]

@ehuss

Is this maybe an executable in a workspace?

Yes, multiple executables, they can easily need different build settings.
In general, crates in the build tree aren't necessarily built together into the same binary.

I encountered the same issue, but with panic instead of lto

`panic` may not be specified in a `package` profile

The worst thing is that there's no reasonable workaround for this (or at least I haven't found one).

[petrochenkov]

10 more people encountered the same issue here - #8264 (comment).

(I consider all of the "may not be specified in a {} profile" errors to be the same issue because in all these cases cargo wrongly assumes that all of the workspace members are always going to be combined into the same binary, which is pretty far from the truth.)

[petrochenkov]

there's no reasonable workaround for this

Looks like it's possible to make a separate profile that inherits from the main one, but overrides panic or lto.
Then the specific package will always be built with that profile.

workspace members are always going to be combined into the same binary

Ugh, looks like different executables may share built dependencies, which is obviously good, but will prevent overriding things like panic.
I guess it's hard for cargo to setup some mini-equivalent of profiles to build dependencies with different panic values separately while keeping everything in a single workspace?

[eldenpark]

Is this being taken care of?

I'm having the same issue. Of many packages and crates in the workspace, I was hoping some specific crates to be compiled with different settings. Specifying profile in the non-root package caused warnings hence I put those in the workspace which throws out errors.

workspace
  - pkg1
    - lib crate
    - lib crate
    - bin crate
  - pkg2
    - lib crate (needs the compilation-specific settings)
  - other pkgs...

[ctrlcctrlv]

Same issue here.

[CPerezz]

Well, in the Cargo documentation it's already mentioned that panic, lto and rpath are not supported.
See: https://doc.rust-lang.org/cargo/reference/profiles.html#overrides at last line of the section.

What I ignore is if it could be supported or not.

[BartMassey]

This is honestly pretty painful. I am giving up on the workspace for my toy example due to this, but it will arise in larger contexts. Anything that could be done to kludge around it?

[vogtb]

I'm experiencing this same issue. Would love a way around this.

[LeoBorai]

Any news on this?