Skip to content

Profile configuration per crate type #16289

@HanabishiRecca

Description

@HanabishiRecca

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-crate-typesArea: crate-type declaration (lib, staticlib, dylib, cdylib, etc.)A-profilesArea: profilesC-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`S-needs-infoStatus: Needs more info, such as a reproduction or more background for a feature request.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions