Tracking issue for custom-named-profile (RFC 2678)

[da-x]

RFC: rust-lang/rfcs#2678
Implementation: #6989
Docs: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#custom-named-profiles

Summary

Adds user-defined profile names.

Unresolved questions:

• Bikeshedding the inherits keyword name. Decided it should be fine.
• Should we keep user profiles under a Toml namespace of their own? Decided to use a flat namespace for simplicity.

For example:

[profile.custom.release-lto]
inherits = "release"
lto = true

* If so, should the `inherits` keyword be able to refer to custom and pre-defined profiles differently?

• Profile names would collide with rustc target names under target/. Should
  the output directory be also under a different namespace, e.g.
  target/custom/release-lto? Decided to use a flat namespace.
• Do we really need pre-defined profiles for test, bench, or can we make them obsolete? Will keep them for now.
• Is it worthwhile keeping test and bench outputs in target/debug and target/release? Doing so would save compilation time and space. Deferred for future target layout reorg.
  • If so, is the dir-name keyword necessary? Alternatively, we can hand-code the output directory of bench and test to be release and debug to keep the current behavior. This may be sufficient until a "global binary cache" feature is implemented, or a per-workspace target/.cache (related discussion). Decided to not expose dir-name and just leave it as a special-case for the built-in profiles.
• Should the PROFILE environment variable in build scripts be deprecated? Currently it only sets DEBUG or RELEASE, which isn't really useful. Should guide users to use DEBUG and OPT_LEVEL instead. Decided to deprecate PROFILE (via documentation).
• Update these commands to support custom named profiles:
  • check
  • rustc
  • fix
  • Any others? Fixed Named profile updates #9685
• What is the interaction with the (future) build profile and unified build directories? Reserved several names in Named profile updates #9685 for adding in the future.
  • Consider making an uber profile above dev/release where build settings could be set (root?)?
• How should automatic target-based profile selection work? For example, today, cargo build --all-targets automatically uses the "test" profile for tests. IIRC, named-profiles changes that behavior. I lean towards the original RFC, where it retains the original behavior, unless --profile is specified, but I am uncertain. Decided to go with a single profile per cargo invocation.
• test inheriting from dev is a change in behavior, will that be a problem? Decided it shouldn't be a major issue.

[ehuss]

A few things that came up during the PR:

How should target-specific profiles be chosen?

Stable cargo uses a variety of factors to choose the profile per compilation unit:

• The --release flag.
• The cargo target (test, bench, etc.).
• The command (mode).
• Which package (for profile overrides).

Dependencies are also special, in that when building a test, the test itself will use the "test" profile, but the dependencies will use "dev". This is done under the assumption that if the test profile is different from dev, you may not want to rebuild the world. The named-profiles feature changes this so that dependencies use the same profile as what is being built. Generally for most projects, this won't matter since most projects keep the test and dev profiles the same.

Some people have found this confusing, and it is a little hard to document clearly. However, it is intended to be intuitive (test targets use the "test" profile). The addition of named profiles makes this even more complex and possibly confusing. Try to answer the question of which profile each unit should use for the following:

• cargo build --test t1
• cargo test --test t1
• cargo test --test t1 --profile=foo
• cargo build --profile=foo --all-targets

One option is to toss away the per-target logic, and use a uniform profile for everything.

Another option is to try to have some elaborate system that tries to retain something like the old behavior.

Another option is to have some sort of target-specific profiles. That is, profile.test could be marked as being the default profile for all tests.

This is a difficult problem, and I'm not really sure where to go with it.

Add named profile support to rustc, check, and fix.

This is a bit tricky, since these commands historically had their own flags:

• cargo rustc:
  • --profile=dev: build (default)
  • --profile=test: test mode and profile (enables cfg(test), etc.)
  • --profile=bench: bench mode and profile
  • --profile=check: check mode
• cargo check and cargo fix:
  • --profile=test: Enables cfg(test), does not change the actual profile.

One option is to add a new flag (--mode?) to take over the old behavior. It's questionable of how these should behave, especially considering backwards compatibility, and consistency with other commands (would cargo build --profile=test enable test mode?). The path forward isn't clear to me.

[michaelwoerister]

This is something l look very much forward to! Is there an estimate of when this will become stable?