Workspace binary artifacts are added to target/debug/deps on Windows

[lopopolo]

Problem

Behavior differs on Windows compared to macOS and Linux when building a workspace where a crate produces binaries. Only on Windows, binaries are placed in target/debug AND target/debug/deps. macOS and Linux only place binaries in target/debug.

target/debug/deps is prepended to the PATH for build scripts. If a workspace produces a binary with the same name as one invoked by a subprocess in a build script, builds after the first will fail on Windows.

Steps

1. Build workspace.
2. Touch build.rs of workspace crate that invokes $binary in its build script.
3. Build workspace.

Possible Solution(s)

Notes

Output of cargo version:

cargo 1.41.0 (626f0f40e 2019-12-03)

Windows, windows-msvc toolchain.

This issue moved here from rust-lang/rust#69318.

[ehuss]

This may be difficult to change or fix. Unfortunately Windows uses PATH for both shared libs (the reason Cargo sets it) and executable paths. Cargo puts the binary in both locations on all platforms, it's just on Windows it does not have a disambiguating hash (due to embedded PDB paths).

However, I suspect executing build scripts probably shouldn't be relying on any local dynamic libraries. One could maybe scan all the crates on crates.io to see if that is the case, but usually the packages that do strange things aren't on crates.io.

Can you say more about your use case? It seems very unusual to both create a binary that shadows a system one, and wanting to execute the original system binary from a build script.

[lopopolo]

The project in question is Artichoke, a Rust implementation of The Ruby programming language. Artichoke uses system Ruby to bootstrap building the standard library.

Artichoke produces a ruby binary to be compatible with MRI (the reference implementation) which also produces a ruby binary. Artichoke’s binary does not have feature parity with MRI. It has no notion of a load path and can not require sources from the host filesystem.

Artichoke vendors a copy of the Ruby repository. These sources contain Ruby source files that implement the standard library. There is no reason to reimplement these for Artichoke.

One of the build scripts in the Artichoke workspace invokes Ruby scripts with the system Ruby, setting the load path to the vendored copy of the standard lib and requires packages one at a time. The invoked Ruby script inspects the loaded constants and source file paths and hands this back to the build script. The build script renders a template for each standard library package that produces a Rust module which loads the standard library package into an Artichoke interpreter.

[epage]

This may be resolved by #15010 because every build unit is isolated to its own directory.