Profile configuration per crate type
Problem
When setting some profile configuration globally it applies to all crate types.
For example, if you enable LTO by setting CARGO_PROFILE_RELEASE_LTO=on env variable or defining it inside the global config.toml.
It is meant to be used for executables, but undesirable say for static libs.
Proposed Solution
It could be useful to be able to define profile configurations per crate type.
Notes
The case I faced personally is compiling git with rust support. It uses a staticlib to link against existing C executables. Which means that the code goes through both rustc own LTO and resulting C compiler LTO.
Not mentioning that double LTO is kinda pointless, the end result is actually worse with rustc LTO enabled, for whatever reason. It decreases the size of libgitcore.a itself, but resulting git executable grows in size instead. Reproducible with both GCC & Clang and variety of linkers.
Which probably shouldn't happen at all, as the rust code here doesn't add any functionality, it just substitutes the identical C code (see varint.rs vs varint.c). So without rustc LTO enabled the binary effectively does not change in size as expected.
But that's another question for compiler/linker devs, I guess.
To me, if not going to build with LTO, I would just not set any flag for that. Also, lto is usually determined on a package basis. If you really need a global preset of profile, perhaps leverage custom profiles, and set one in ~/.cargo/config.toml like this
[profile.release-lto]
inherits = "release"
lto = true
And then run cargo build --profile release-lto.
That said, I have no idea what your workflow looks like. Would be helpful if you could provide more details of it :)
There is no particular workflow. I just want all apps to be build with LTO on. Not all crates set it. That's not the main point of the request though, LTO is just an example.
leverage custom profiles
That's obvious. If you control the build, you can just set CARGO_PROFILE_RELEASE_LTO on per package basis. But that's just inconvinient and you need to manually analyze the type of each crate.
Also git in particular uses meson build system and you don't invoke cargo directly. It's done inside their build script instead. (Or inside the makefile if you use classic GNU make.)
I want this feature as well. In a package, some of artifacts should be optimized, while some of artifacts should be fast to compile. At the moment, I can only achieve it by manually running cargo rustc -- -Clto=off. I don't want to use two profiles, since compiling twice would obviously be slower.