Configurable directory for temp files that isn't the target dir

[kornelski]

Currently CARGO_TARGET_DIR is a mix of two distinct functionalities:

1. location where temporary/intermediate build files are placed
2. location where final build artifacts are placed

I'm finding that it's useful for me to have these two directories separate, as I treat temporary and non-temporary files differently.

Use-cases:

Working on NFS

I'm using Cargo in a virtual machine to work on a Linux-only project. But I'm a Mac user, so my project is on a network drive in the VM (vagrant), so that I can edit files easily from the host machine.

It's convenient to have built executables in the easily-accessible ./target. OTOH the network drive is very slow, flaky, doesn't support hard links, and it makes rebuilds sloooow, so having intermediate build files in ./target is painful.

Easy cleanup of temp files

Temp dirs in the target directory can be huge — a few GB large. I have an SSD which is almost full, so I can't afford having a few GB of temp files just laying here and there all over the disk, and I have to regularly go and delete the target directories in all projects I'm working on. The problem is that I have my Rust projects intentionally in various folders, so to delete the temp files I have to look for them in several places.

I'd rather set a single system-global temp directory such as /var/tmp/cargo/%some_hash_of_project/ (#6210) which is easy to delete (and on macOS it could be in the proper ~/Library/Caches).

Integration with Xcode

Xcode already has distinction between "intermediate" files and "products". From Xcode's perspective CARGO_TARGET_DIR conflates the two, so it doesn't map well to Xcode's configuration. For cargo-xcode I had to add workaround for this.

---

I think it could be solved by supporting a variable like CARGO_TEMP_DIR that would configure cargo to place the ./target/<profile>/{build,native,.fingerprint,incremental} directories somewhere inside CARGO_TEMP_DIR.

[phiresky]

Yes please. I'm currently trying to figure out how to prevent my backup system from backing up 10GB of "useless" build artifacts, which still including the repository and possibly useful final builds.

[michalfita]

My use case is related to AI antivirus & antimalware - software has to be built in a special directory, otherwise sometimes binaries are sent to quarantine and the whole build killed. This especially affects cargo install.

[kornelski]

Related PRs:

#8686
#8063

[spoelstraethan]

I was able to work around this by specifying CARGO_TARGET_DIR=/usr/local/tmp and CARGO_INSTALL_ROOT=/usr/local to have it put the binaries where the system would find them (if /usr/local/bin is in the PATH), and also to handle the case that on my system $HOME/.cargo and /tmp both live on noexec mounts, so I can't use the default $HOME/.cargo/bin or alternate $HOME/.local/bin paths or /tmp for the building or outputs because many things fail to build if they can't execute an intermediate binary.

[codyps]

I was able to work around this by specifying CARGO_TARGET_DIR=/usr/local/tmp

@spoelstraethan when setting CARGO_TARGET_DIR like this (so that it's shared), built executables/libs may use unexpected code, see #12516

[epage]

Does #6790 remove the need for this? CARGO_TARGET_DIR would be the tmp directory and --out-dir would be for final artifacts?

[epage]

This looks to be the same as #14125, closing in favor of that.