Clean Build Folder eller slette DerivedData i Xcode?

Forskjellen er omfanget, ikke grundigheten

Product > Clean Build Folder (Skift-Kommando-K) virker innenfor prosjektet og schemet du har åpent. Kommandoen kaster de kompilerte produktene og mellomfilene for akkurat det oppsettet, slik at neste bygg starter fra kildekoden. Den gjelder bare ett prosjekt og beholder med vilje det som er dyrt å bygge opp igjen.

DerivedData er mappen på toppnivå som deles av alle prosjekter som bruker standardplasseringen – ~/Library/Developer/Xcode/DerivedData, med én undermappe per prosjekt eller arbeidsområde du noen gang har åpnet. Sletter du én undermappe, nullstilles nøyaktig det prosjektet. Sletter du hele mappen, må alle prosjektene dine bygges og indekseres på nytt neste gang du åpner dem.

Den ærlige beskrivelsen er derfor ikke «lett rengjøring» mot «grundig rengjøring». Clean Build Folder er smal og billig; å slette DerivedData er bredt og koster deg indeksen. Hva som er riktig, avhenger helt av om det som er ødelagt, ligger i byggeproduktene eller utenfor dem.

Start smalt når bygget feiler

Dukket feilen opp rett etter at du byttet gren, endret en byggekonfigurasjon eller redigerte ressursfiler, avslutter du appen som kjører, og bruker Clean Build Folder først. Det er den billigste nullstillingen du har, den bevarer indeksen, og du er tilbake i arbeid etter ett bygg – ikke ett bygg pluss flere minutter med indeksering.

Gå videre til å slette prosjektets DerivedData-mappe når symptomene egentlig ikke handler om byggeprodukter: Xcode viser feil i kode du allerede har rettet, «Jump to Definition» havner på feil sted, eller kodefullføringen har sluttet å forstå dine egne typer. Det er tegn på problemer med indeksen, og Clean Build Folder rører ikke indeksen.

Ett tilfelle er verdt å kjenne til, fordi det er den vanlige grunnen til at «jeg kjørte Clean, og det hjalp ikke» blir til «jeg slettet DerivedData, og da gikk det»: Cachen for forhåndskompilerte moduler (ModuleCache.noindex) ligger i roten av DerivedData, ikke i undermappen til et prosjekt. Clean Build Folder når den aldri. Blir modulcachen utdatert etter en endring av SDK eller verktøykjede, forsvinner feilen bare når du fjerner den.

Ingen av kommandoene retter en faktisk feil i kildekoden eller avhengighetene dine. Får du nøyaktig samme feil etter et rent bygg, bør du slutte å rydde og lese kompilatormeldingen – årsaken ligger i prosjektinnstillingene, Package.resolved, valgt SDK eller selve koden.

Ingen av dem er en strategi for diskopprydding

Clean Build Folder er et diagnoseverktøy som tilfeldigvis frigjør noen byte. Det kan gi tilbake plass for det gjeldende prosjektet, men byggeproduktene til alle andre prosjekter, alle indekser og modulcachen blir liggende akkurat der de var. Å kjøre det for å få tilbake diskplass er å måle feil ting.

Er plass det egentlige målet, går du motsatt vei: Mål undermappene i DerivedData først, og slett deretter prosjektene du ikke har åpnet på flere måneder. Det er vanligvis der titalls gigabyte ligger – engangskloner du bygde én gang og aldri gikk tilbake til.

Ikke begynn med rm -rf. I Finder kan du flytte de valgte mappene til Papirkurven, der de kan hentes tilbake helt til du tømmer den – og den forskjellen betyr noe første gang du sletter mappen til et prosjekt som viser seg å bygge akkurat nå. Terminal lønner seg for automatisering, men først når du har bekreftet den nøyaktige stien.

Kontroller resultatet i stedet for å stole på et tall

Noter størrelsen på DerivedData før du gjør noe, bruk nøyaktig ett av de to alternativene, og mål på nytt. Etter Clean Build Folder bygger du det aktive schemet. Har du slettet en DerivedData-mappe, åpner du Xcode og venter til det første bygget og indekseringen er ferdige.

Gjør du det i den rekkefølgen, kan du skille plassen du fikk tilbake, fra prisen du betalte for den. Det finnes ikke noe universelt tall å forvente: Resultatet avhenger av hvor mange prosjekter, konfigurasjoner og arkitekturer som er bygget på akkurat denne Macen.

Hva du bør velge

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

Vanlige spørsmål