Xcode: Clean Build Folder eller slet DerivedData?

Forskellen er omfanget, ikke grundigheden

Product > Clean Build Folder (Skift-Kommando-K) virker inden for det projekt og det scheme, du har åbent. Kommandoen smider de kompilerede produkter og mellemfiler for netop den sammenhæng ud, så næste build starter fra kildekoden. Den gælder kun ét projekt og beholder bevidst det, der er dyrt at genopbygge.

DerivedData er den overordnede mappe, som alle projekter med standardplaceringen deler — ~/Library/Developer/Xcode/DerivedData med én undermappe for hvert projekt eller workspace, du nogensinde har åbnet. Sletter du én undermappe, nulstiller du præcis det projekt. Sletter du hele mappen, skal alle dine projekter bygges og indekseres igen, næste gang du åbner dem.

Den ærlige beskrivelse af de to er derfor ikke ”en let oprydning” over for ”en hovedrengøring”. Clean Build Folder er snæver og billig; sletning af DerivedData er bred og koster dig indekset. Hvad der er det rigtige valg, afhænger helt af, om det, der er gået i stykker, ligger i build-produkterne eller uden for dem.

Når et build fejler, så start snævert

Dukkede fejlen op lige efter, at du skiftede branch, ændrede en build-konfiguration eller redigerede ressourcefiler, så stop den app, der kører, og brug Clean Build Folder først. Det er den billigste nulstilling, der findes, den bevarer indekset, og den får dig tilbage i arbejde efter ét build i stedet for ét build plus flere minutters indeksering.

Gå videre til at slette projektets DerivedData-mappe, når symptomerne ikke rigtig handler om build-produkter: Xcode viser fejl i kode, du allerede har rettet, ”Jump to Definition” lander det forkerte sted, eller kodefuldførelsen er holdt op med at forstå dine egne typer. Det er symptomer på et indeksproblem, og Clean Build Folder rører ikke indekset.

Ét bestemt tilfælde er værd at kende, fordi det er den typiske grund til, at ”jeg kørte Clean Build Folder, og det hjalp ikke” bliver til ”jeg slettede DerivedData, og så virkede det”: Den forudkompilerede modulcache (ModuleCache.noindex) ligger i roden af DerivedData, ikke i et projekts undermappe. Clean Build Folder når den aldrig. Bliver modulcachen forældet efter en ændring af SDK eller værktøjskæde, forsvinder fejlen kun, hvis du fjerner den.

Ingen af de to retter en egentlig fejl i din kildekode eller dine afhængigheder. Overlever præcis den samme fejl et clean build, så hold op med at rydde op, og læs compilerens fejlmeddelelse — årsagen ligger i projektindstillingerne, Package.resolved, det valgte SDK eller selve koden.

Ingen af dem er en oprydningsstrategi

Clean Build Folder er et diagnoseværktøj, der tilfældigvis frigør lidt plads. Det kan give plads tilbage for det aktuelle projekt, men alle andre projekters build-produkter, alle indekser og modulcachen bliver liggende præcis, hvor de var. Kører du det for at få diskplads tilbage, måler du på det forkerte.

Er plads det egentlige mål, så gå den anden vej: Mål først undermapperne i DerivedData, og slet derefter de projekter, du ikke har åbnet i flere måneder. Det er typisk dér, de mange gigabyte ligger — engangskloner, du byggede én gang og aldrig vendte tilbage til.

Start ikke med rm -rf. I Finder kan du flytte de valgte mapper til papirkurven, hvor de kan gendannes, indtil du tømmer den — og den forskel betyder noget, første gang du sletter mappen til et projekt, der viser sig at blive bygget lige nu. Terminal er god til automatisering, men først når du har bekræftet den præcise sti.

Tjek resultatet i stedet for at stole på et tal

Noter, hvor meget DerivedData fylder, før du gør noget, brug præcis én af de to muligheder, og mål så igen. Efter Clean Build Folder bygger du det aktuelle scheme. Efter sletning af en DerivedData-mappe åbner du Xcode og venter, til det første build og indekseringen er færdige.

Gør du det i den rækkefølge, kan du skille den plads, du fik tilbage, fra den pris, du betalte for den. Der findes ikke noget universelt tal at forvente: Resultatet afhænger af, hvor mange projekter, konfigurationer og arkitekturer der er bygget på netop den Mac.

Hvad skal du vælge?

Tabellen beskriver omfang, ikke et lovet antal gigabyte. Mål din egen Mac før og efter.

FAQ