I would like to proposed named custom profiles in Cargo.
(EDIT: RFC opened: RFC 2678)
Past proposal to increase flexibility of Cargo’s build flags for crates within a single
cargo build invocation, has resulted in RFC 2282, which adds the flexibility of changing attributes of specific crates under one of the default profiles. However, useful as it is, it does not allow for a full custom profile name definition that can have its own separate directory under
target, in parallel to
First, it I think it would be worth to note that I don’t regard this extension as making the previous
overrides extension unnecessary. Rather, I think it is in fact orthogonal and complementary to it.
The motivation for having named custom profiles is to be able to easily throw everything under a custom compilation mode, which is chosen when Cargo is invoked from the command-line, just like
--release is chosen. For example, if suppose I am frequently comparing between both a release build and a super-optimized release+LTO build, I would like Cargo to having two separate
target/ directories, e.g.
target/release-lto, for which the binaries and incremental compilation is managed separately. This is so that I can easily switch between the two modes without penalty.
Here’s an example actual real-world user: tikv/issue/4189
This proposal’s design is simple - let the user define profiles under new names, keeping the original names reserved, and allow the new profiles to inherit from existing ones. The exact
Cargo.toml structure can be as such:
[profile.custom.release-lto] inherits = "release" lto = true
--profile with the profile’s name to various cargo commands will resolve as if we used the inherited profile, with the overrides specified in the inheriting profiles, and all outputs will go to a different directory.
$ cargo build $ cargo build --release $ cargo build --profile release-lto $ ls -l target debug release release-lto
Having this result in a separate directory is important, because the intended use of this feature is usually to affect the build flags for all dependent crates anyway, and because we cannot currently have the same crate be built with different flags under the same profile.
- Is there a cleaner way to accomplish this now?
- Bike-shedding whether we call this ‘inherit’ or something else (
- What restrictions to put on profile names
cargo cleanbehave regarding the custom profile output directories