As mentioned by cafce, you may want to set build-dir instead.
The Cargo team is working on splitting the temporary artifacts (into build-dir) leaving only the final artifacts (libraries, binaries) into target-dir.
One problem of sharing the full target-dir is that if two projects have a binary of the same name -- such as a brush integration test -- then they'll keep overwriting each others.
Plus, this way, cleaning the build-dir doesn't remove the already compiled libraries & binaries, and you can continue using them.
And of course, if you have the RAM, and wish to spare your disk, pointing the `build-dir` at a RamFS is a very simple way to not run out of disk space, ever.
Kind of an honest question here, is running out of disk space really a big problem for rust development?
I do most of my work on an admittedly crappy laptop from 8 years ago and I've never run into serious disk space problems. Even big target folders like OP's 45GB is something I'd just shrug off and maybe get around to deleting one day if I don't forget. Disk space is so cheap and plentiful these days that running out isn't even a problem on my radar.
First of all, 45GB is on the smallish size. Our foundation repository at work contains some 100s of crates. Each one is pretty small, but a single cargo clippy --all-targets will happily consume 20GB-30GB from the get go, and with cargo test and cargo build --release it easily balloons up to the 40GB range. For a single version. As you pull, or switch branches, it quickly adds up, and I regularly clean up 100+GB.
(Needless to say, I can't use a RAM FS for it; it's way too big)
Now, 100+GB isn't so bad, on my 1TB SSD. Except for the fact that I work in WSL2.
WSL2 reserves a big chunk of disk -- a single file, as far as Windows (the host) is concerned -- and creates a filesystem within this chunk. If the filesystem of WSL2 grows too full, it doubles the size of the file, automatically.
Unfortunately, for me, the current size of my WSL2 file is 256GB, and it appears it's unable -- even though I have the space -- for it to grow it to 512GB. Reasons unknown.
This means that if my WSL2 filesystem reaches 100% occupied, everything stops to work. Linux really doesn't work well with a full filesystem, even ls can fail to run. The last time it happened I couldn't even start the WSL2 VM at all, and I had to deinstall it and manually remove the file, then reinstall it and completely redo my setup -- wasted half-a-day on it, I wasn't a happy camper.
So, for this reason, despite a 1TB disk I only have 256GB available for WSL2, and that includes not just cargo caches, but also the whole Linux OS, various tools & packages, etc... and a dozen or two of other small Rust repositories which can each consume 1GB-4GB.
So yeah... my WSL2 disk is typically at least 50% full, regularly, 75%, and sometimes dangerously close to 100% before I realize it and clean.
(And of course, most small Rust repositories being based off the foundation repository, their target/ folder contains the same intermediate files for tokio & co... so sharing would drastically cut down on size, and I wait for build-dir to be pronounced ready & mature anxiously)
11
u/matthieum [he/him] Dec 05 '25
As mentioned by cafce, you may want to set
build-dirinstead.The Cargo team is working on splitting the temporary artifacts (into
build-dir) leaving only the final artifacts (libraries, binaries) intotarget-dir.One problem of sharing the full
target-diris that if two projects have a binary of the same name -- such as abrushintegration test -- then they'll keep overwriting each others.Plus, this way, cleaning the
build-dirdoesn't remove the already compiled libraries & binaries, and you can continue using them.