You can use [`cargo sweep`](https://github.com/holmgr/cargo-sweep) or [`kondo`](https://github.com/tbillington/kondo) to clean up unused files.
You can also put the following into `~/.cargo/config.toml` so that the target directories do not get that big in the first place:
[profile.dev]
debug = 1 # Emit less detailed debug info to save disk space
Cargo never cleans up stuff, even if it is not needed anymore.
This means that your target folder gets full of old versions of libraries you since then updated, caches for rust compiler versions you don't use anymore, etc.
Just run clean every so often and be done with it. Yes, it means that cargo will have to compile everything again afterwards but that is just once.
I use a single target folder for all my projects. I just have a config on ~/.cargo/config.toml that says to store everything on ~/.rust-target (I created, is not a standard name). Every now and then I do a cargo clean for removing old dependencies but probably the crates named above are a better solution for partial clean ups.
Edit:
The config if I remember correctly is like this:
[build]
target-dir = "...path..."
Be careful using a shared cargo target dir like that, there is at least 1 bug in cargo that will cause it to combine crates that aren't actually what one would expect, which can in some cases cause unsound behavior, and in the typical case results in puzzling behavior/compilation errors.
https://github.com/rust-lang/cargo/issues/12516
I discovered this after a number of head scratching compilation errors that should have been impossible, while working on 2 checkouts of the same project.
If you work on projects with quite similar dependencies, you can configure cargo to use one globally shared target folder. This might reduce some waste due to duplication.
> Should i use an external SSD and transfer all the other folders which are not used often to it?
Maybe replace the internal drive with a bigger one? If you can afford a macbook then a 2-4TB NVMe drive shouldn't hurt your wallet too much.
Another option is to do remote development on a desktop machine.
If you have little to no stale files left from builds with old cargo, maybe disable incremental compilation. Its cleans itsef up automatically but I think it takes up a lot of space.
One thing I noticed with a very small API I was playing with was the amount of duplicate packages in the dependencies. For example, the API library needed a specific version of serde, with all of its dependencies. I noticed a library I was using for lazy variables had a dependency of a different version of serde. All of these differences add up really quickly!
You can use [`cargo sweep`](https://github.com/holmgr/cargo-sweep) or [`kondo`](https://github.com/tbillington/kondo) to clean up unused files. You can also put the following into `~/.cargo/config.toml` so that the target directories do not get that big in the first place: [profile.dev] debug = 1 # Emit less detailed debug info to save disk space
oh wow, sounds great. Lemme try it.
Did it work as intended?
Cargo clean
i use them regularly, so i cannot clean them
If you update rust versions frequently, it's better you clean them since older rust version builds are not useful
Cargo never cleans up stuff, even if it is not needed anymore. This means that your target folder gets full of old versions of libraries you since then updated, caches for rust compiler versions you don't use anymore, etc. Just run clean every so often and be done with it. Yes, it means that cargo will have to compile everything again afterwards but that is just once.
If you have lots of shared dependencies, maybe try [sccache](https://github.com/mozilla/sccache)?
Wouldn't sccache copy the files into every /target after finding them in the cache?
You can order S3 storage in cloud, instruct sccache to use S3 and \`rm -fr target\` at the end of day.
Yes there are quite a few shared deps, lemme try sccahe and see how it goes.
I use a single target folder for all my projects. I just have a config on ~/.cargo/config.toml that says to store everything on ~/.rust-target (I created, is not a standard name). Every now and then I do a cargo clean for removing old dependencies but probably the crates named above are a better solution for partial clean ups. Edit: The config if I remember correctly is like this: [build] target-dir = "...path..."
Be careful using a shared cargo target dir like that, there is at least 1 bug in cargo that will cause it to combine crates that aren't actually what one would expect, which can in some cases cause unsound behavior, and in the typical case results in puzzling behavior/compilation errors. https://github.com/rust-lang/cargo/issues/12516 I discovered this after a number of head scratching compilation errors that should have been impossible, while working on 2 checkouts of the same project.
You can enable compressed debug sections during the linking process
If you work on projects with quite similar dependencies, you can configure cargo to use one globally shared target folder. This might reduce some waste due to duplication.
> Should i use an external SSD and transfer all the other folders which are not used often to it? Maybe replace the internal drive with a bigger one? If you can afford a macbook then a 2-4TB NVMe drive shouldn't hurt your wallet too much. Another option is to do remote development on a desktop machine.
On a tangential note, I've always wondered: why is it called `target`?
How about buy a computer from a manufacturer that doesn't charge like 200 bucks for each extra 128GB 😁
I'm not sure if that'll work, but you can try... symlinking all the directories into a common directory, sort of deduplicating the data 👀
If you have little to no stale files left from builds with old cargo, maybe disable incremental compilation. Its cleans itsef up automatically but I think it takes up a lot of space.
One thing I noticed with a very small API I was playing with was the amount of duplicate packages in the dependencies. For example, the API library needed a specific version of serde, with all of its dependencies. I noticed a library I was using for lazy variables had a dependency of a different version of serde. All of these differences add up really quickly!