cargo build --all-targets executes build.rs twice in beta and nightly

[stepancheg]

build.rs

Repro

clone https://github.com/stepancheg/cargo-build-rs-twice
cd cargo-build-rs-twice

Stable:

% rm xx/*; cargo +stable build --all-targets && ls xx/
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling libc v0.2.41
   Compiling fgfgf v0.1.0 (file:///Users/nga/tmp/cargo-build-rs-twice)
    Finished dev [unoptimized + debuginfo] target(s) in 2.59 secs
50421

Nightly:

% rm xx/*; cargo +nightly build --all-targets && ls xx/
   Compiling libc v0.2.41
   Compiling fgfgf v0.1.0 (file:///Users/nga/tmp/cargo-build-rs-twice)
    Finished dev [unoptimized + debuginfo] target(s) in 2.85s
50513	50514

build.rs writes a pid file into xx/ directory.

Two pid files in xx directory mean that build.rs was executed twice in nightly.

% cargo +nightly version
cargo 1.28.0-nightly (f352115d5 2018-05-15)
% cargo +stable version
cargo 1.26.0 (0e7c5a931 2018-04-06)

[matklad]

This is sort-of intentional behavior change. When executing build scripts, Cargo passes env-vars like PROFILE, OPT_LEVEL and such, which could be different for lib, tests and becnhmarks. Previously, cargo executed build.rs once, but that could have been wrong.

@ehuss @alexcrichton we've decided that this is an ok change of behavior, but probably it isn't? I certainly see how this could be surprising, and that in the common case, when build.rs does not inspect those env-vars, this could lead to genuinely duplicated work as well.

[matklad]

cc #5384, which introduced the changes.

[ehuss]

Related to #4929 there's a question about how build should handle benchmarks if you don't specify --release. If we built them in dev mode, that would fix this issue†. I'm warming up to that idea, it would be more consistent. It would also provide a means to more easily debug a benchmark if they desire. I imagine it is rare that someone will try to build a benchmark and then run it manually (unless there is some IDE that does this instead of running bench?). build --release --bench ... would continue to use the "bench" profile.

I'm not sure how surprising build --benches building with "test" profile would be.

Let me know what the cargo team thinks of that idea, and I can work on it.

† Overridden test profile with different debug or opt-level would still trigger this behavior.

[alexcrichton]

I'm personally ok with the change as is, but I agree with @ehuss that perhaps the best thing to do here is to have cargo build build nothing in release mode. I think that'd be a good solution for this!