Rust's target/ folder is designed to be safe to share (happy to be corrected!)

So I just symlinked it across all project's worktrees :)

Saves a lot (lot!) of disk

The only issue I faced was that target then becomes a symlink, and the (conventional) .gitignore was target/, so I needed to add a local .git/info/exclude

#rustlang

@mnvr As far as I remember there's cargo's global setting to have common target directory for the similar reason. The trouble starts when you have any tools relying on presence of `target/` and it's content.
@michalfita Yes! There's CARGO_TARGET_DIR, I was tempted ngl :), but in my case the problem was much more tractable — monorepo and a fixed set of workspaces, so I thought I'll go with the more deterministic solution.
@mnvr Sharing a target directory is not a blessed workflow but a "we try not to break it". There are many problems. Some are fixed by only sharing `build-dir` and not `target-dir` so there aren't conflicts with final artifacts. Soon we'll stabilize a new `build-dir` layout that will reduce conflicts among intermediate artifacts. That still leaves issues with lock contention we hope to fix one day.
@epage Thank you even for a "we try not to break it", I'll take it :) I'm was happy that Rust is even trying to handle this.
@mnvr @epage you also limit yourself to one concurrent compilation across your entire machine no?
@unsafe @mnvr Yes, that was my note at the end.

@unsafe @epage Not really! 😮My understanding is that there is "lock contention", so it won't be efficient, but the artifacts will still be correct, no?

In my specific case, I have a monorepo and 4 (+1) worktrees. And it is quite infrequent (but not impossible) for me to be compiling the same bit of Rust across two worktrees. So the way I've taken lock contention is — I shouldn't arrange for contention to happen frequently, but if it does happen rarely, no harm done.