CARGO_PRIMARY_PACKAGE is set for dependencies inside workspace

[leighmcculloch]

Problem

The Cargo reference states:

• CARGO_PRIMARY_PACKAGE — This environment variable will be set if the package being built is primary. Primary packages are the ones the user selected on the command-line, either with -p flags or the defaults based on the current directory and the default workspace members. This environment variable will not be set when building dependencies. This is only set when compiling the package (not when running binaries or tests).

Ref: https://doc.rust-lang.org/cargo/reference/environment-variables.html

Specifically this statement is not always true:

This environment variable will not be set when building dependencies.

However, it appears the env var will be set when a crate in a workspace is being built, even when used as a dependency of another crate.

Without CARGO_PRIMARY_PACKAGE always being not set for dependencies, it is not possible to accurately detect if a crate is being built for use as a dependency or not.

Steps

See example repo: https://github.com/leighmcculloch/rustlang--cargo--issue-10956

Running the Makefile in the repo produces:

---- build workspace, and run bbb
cargo clean
cargo build
   Compiling aaa v0.1.0 (/Users/leighmcculloch/Code/rusttest/aaa)
   Compiling bbb v0.1.0 (/Users/leighmcculloch/Code/rusttest/bbb)
    Finished dev [unoptimized + debuginfo] target(s) in 0.34s
cargo run bbb
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/bbb bbb`
bbb: true
aaa: true
---- build bbb, and run bbb
cargo clean
cargo build -p bbb
   Compiling aaa v0.1.0 (/Users/leighmcculloch/Code/rusttest/aaa)
   Compiling bbb v0.1.0 (/Users/leighmcculloch/Code/rusttest/bbb)
    Finished dev [unoptimized + debuginfo] target(s) in 0.33s
cargo run bbb
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/bbb bbb`
bbb: true
aaa: false
---- build workspace (again), and run bbb
cargo clean
cargo build
   Compiling aaa v0.1.0 (/Users/leighmcculloch/Code/rusttest/aaa)
   Compiling bbb v0.1.0 (/Users/leighmcculloch/Code/rusttest/bbb)
    Finished dev [unoptimized + debuginfo] target(s) in 0.34s
cargo run bbb
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
     Running `target/debug/bbb bbb`
bbb: true
aaa: false

Note that in the second build and run aaa thinks it is primary, even when it is used as a dependency.

Note that in the third build and run aaa knowledge of whether it is primary is unstable, because building the workspace in the final run produces a different result as the first run.

Possible Solution(s)

No response

Notes

It appears that CARGO_PRIMARY_PACKAGE is also unstable. If I cd into the B crate directory and build, A will be built as a dependency with the env var not set. If I then cd into the workspace directory and built all crates in the workspace, the A crate is not rebuilt, meaning the cached built artifact for A is inconsistent with a clean build.

Version

cargo 1.62.1 (a748cf5a3 2022-06-08)
release: 1.62.1
commit-hash: a748cf5a3e666bc2dcdf54f37adef8ef22196452
commit-date: 2022-06-08
host: aarch64-apple-darwin
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.79.1 (sys:0.4.51+curl-7.80.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 12.4.0 [64-bit]

[epage]

Building in the workspace root implicitly selects all packages to build which fits with

Primary packages are the ones the user selected on the command-line, either with -p flags or the defaults based on the current directory and the default workspace members

I can see us not rebuilding by default if this changed. If you want to force re-running when it changes, cargo:rerun-if-env-changed=VAR would be useful.

So for me, the question is why did a clean build of the workspace produce different results.

[ehuss]

Thanks for putting together the reproduction!

It might be reasonable to include is_primary_package in the fingerprint so that it will rebuild. (As long as it doesn't severely impact clippy. It seems fairly risky to change.)

I suppose the docs could also be clarified. In this example, a workspace member is both a primary unit and a dependency for another member. "dependencies" was just used a short form of "everything that is not a root". It might be difficult to describe that without being too wordy or technical.

Also, FYI, in your reproduction, the calls to cargo run bbb probably aren't doing what you expect. The argument bbb is passed as an argument to the executable; it isn't used by Cargo to select the bbb package (that requires -p or --bin).

[ehuss]

Sorry, I meant for this issue to track two separate things (docs, and the fingerprint bug), but I should have separated them. I opened #14678 specifically for the inconsistent fingerprinting.