Dossier target Rust trop gros : pourquoi, et quoi supprimer

Dix projets Rust, dix dossiers target, 40 Go. Ce qu'il y a dedans, et comment le contenir sans renoncer aux builds incrémentaux.

Mis à jour le 2026-08-13

Ce qu'il contient

target/ se reconstruit entièrement à partir de ton code source et de ton fichier de verrouillage. Le supprimer ne peut faire perdre aucun travail. S'il grossit autant, c'est que Cargo garde bien plus que le binaire que tu as demandé.

Contenu	Pourquoi c'est gros
Chaque dépendance, compilée	Un arbre de 300 crates donne 300 rlibs, et ce pour chaque profil.
Symboles de débogage	Un binaire debug non épuré pèse couramment 10 à 50 fois un build release.
État de la compilation incrémentale	Empreintes et fragments en cache par crate, sous target/debug/incremental.
Un dossier par profil	debug, release et chaque profil personnalisé, chacun en copie complète.
Un dossier par triplet de cible	La compilation croisée double ou triple le tout.
Binaires de tests et de benchmarks	Chaque test d'intégration est un exécutable lié à part entière.

Rien de tout ça n'est une fuite. C'est le prix des builds incrémentaux, et c'est en général un bon compromis, jusqu'au jour où tu as trente dépôts sur le disque dont vingt-neuf n'ont pas été touchés depuis le printemps.

Trouver où est passée la place

$ du -sh target

Un seul projet.

$ find ~/dev -maxdepth 3 -type d -name target -prune -exec du -sh {} + | sort -h

Tous les dossiers target sous ~/dev, du plus petit au plus gros. Adapte le chemin et la profondeur à ton organisation.

$ cargo clean --dry-run

Montre ce qui serait supprimé, sans rien supprimer. Disponible dans les versions récentes de Cargo.

Nettoyer, du plus doux au plus radical

$ cargo clean -p my-crate

Supprime les artefacts d'un seul paquet et garde toutes les dépendances compilées. En général, c'est tout ce qu'il faut après un changement de version.

$ cargo clean --release

Supprime uniquement le profil release. Tes builds debug incrémentaux, rapides, restent intacts.

$ rm -rf target/debug/incremental

Supprime uniquement l'état incrémental. Souvent 30 à 50 % d'un dossier debug, et il se reconstruit sans que tu t'en rendes compte.

$ cargo clean

Tout. Le build suivant part de zéro : plusieurs minutes sur un gros arbre de dépendances.

Préfère cargo clean à rm -rf target quand le projet est sur le disque : Cargo connaît les dossiers target personnalisés définis par CARGO_TARGET_DIR ou config.toml, alors qu'un rm à l'aveugle les ratera.

Sur plusieurs projets à la fois

cargo-sweep sait quels artefacts appartiennent à des toolchains que tu n'utilises plus : c'est l'outil de nettoyage en masse le plus sûr :

$ cargo install cargo-sweep

Installation unique.

$ cargo sweep --time 30 --recursive ~/dev

Supprime les artefacts auxquels personne n'a accédé depuis 30 jours, dans tous les projets sous ~/dev. Ton travail récent reste rapide.

$ cargo sweep --installed --recursive ~/dev

Supprime les artefacts compilés par des toolchains qui ne sont plus installées. De la perte pure, aucun inconvénient.

Garder la taille sous contrôle

Le changement le plus efficace, de loin, est un dossier target partagé. Une seule copie compilée de serde au lieu de trente.

$ echo -e "[build]\ntarget-dir = \"$HOME/.cargo/shared-target\"" >> ~/.cargo/config.toml

Tous les projets compilent dans un même dossier partagé. Une dépendance compilée une fois est réutilisée partout.

$ rm -rf ~/.cargo/registry/src

Les sources de crates extraites. Cargo les réextrait des archives .crate à la demande. Sans risque, et souvent 1 à 3 Go.

Un dossier target partagé sérialise les builds entre projets : deux cargo build lancés dans des dépôts différents attendront désormais le même verrou. Sur un portable où tu compiles une chose à la fois, ça ne se voit pas. En CI, garde-les séparés.

debug = 1 dans [profile.dev] divise par deux la taille des infos de débogage, presque sans perte sur la qualité des backtraces.
split-debuginfo = "unpacked" sur macOS sort les symboles des binaires eux-mêmes.
Ajouter target/ au .gitignore est la norme, mais vérifie qu'il y est bien : un dossier target commité, c'est un genre bien particulier de mauvaise journée.

Est-ce sans risque de supprimer target/ ?

Toujours. Il ne contient ni code source ni configuration, et il se reconstruit à partir de ton code et de Cargo.lock. Le seul coût, c'est un build à froid.

Pourquoi mon build debug est-il tellement plus gros que le release ?

Les symboles de débogage et l'état de la compilation incrémentale. Un build release en retire l'essentiel et ne garde pas de fragments incrémentaux par défaut.

Un dossier target partagé casse-t-il quelque chose ?

Il sérialise les builds simultanés derrière un seul verrou, et il rend plus difficile de « supprimer les artefacts de ce projet ». Sur la machine d'un développeur seul, la place gagnée vaut en général ces deux inconvénients.

Dois-je supprimer ~/.cargo/registry ?

Le sous-dossier `src`, oui : il est extrait d'archives que tu as encore. Supprimer `cache` oblige à retélécharger chaque crate, ce qui est plus lent et moins correct envers crates.io.

La version automatique

Tout ce qui précède marche, ne coûte rien et continuera de marcher. Loupe fait la même chose sur tous les projets du disque à la fois, et montre ce que chaque suppression coûtera à reconstruire avant que tu l'acceptes.

BientôtLoupe

Guides voisins