Xcode: Clean Build Folder, nebo smazání DerivedData?

Rozdíl je v rozsahu, ne v důkladnosti

Product > Clean Build Folder (Shift-Command-K) pracuje uvnitř projektu a schématu, které máte právě otevřené. Zahodí zkompilované produkty a mezivýstupy pro tento kontext, takže další sestavení začne od zdrojového kódu. Týká se jediného projektu a záměrně ponechává to, co je nákladné vytvářet znovu.

DerivedData je nadřazená složka, kterou sdílejí všechny projekty používající výchozí umístění – ~/Library/Developer/Xcode/DerivedData, s jednou podsložkou pro každý projekt nebo workspace, který jste kdy otevřeli. Smazáním jedné podsložky resetujete právě tento projekt. Smažete-li celou složku, každý váš projekt se při příštím otevření znovu sestaví a znovu zaindexuje.

Poctivě řečeno tedy nejde o „lehké“ a „hloubkové“ čištění. Clean Build Folder je úzký a levný zásah; smazání DerivedData je široké a přijdete při něm o index. Která možnost je správná, závisí jen na tom, zda je to, co se rozbilo, uvnitř produktů sestavení, nebo mimo ně.

Když sestavení selže, začněte nejmenším zásahem

Pokud se chyba objevila hned po přepnutí větve, změně konfigurace sestavení nebo úpravě souborů prostředků (resources), ukončete spuštěnou aplikaci a nejdřív použijte Clean Build Folder. Je to nejlevnější dostupný reset, index zůstane zachovaný a k práci se vrátíte po jediném sestavení, ne po sestavení a několika dalších minutách indexování.

Ke smazání složky DerivedData daného projektu přistupte, když příznaky ve skutečnosti nesouvisejí s produkty sestavení: Xcode hlásí chyby v kódu, který už jste opravili, skok na definici vás zavede na špatné místo nebo našeptávání přestalo rozumět vašim vlastním typům. To jsou příznaky problému s indexem a Clean Build Folder se indexu nedotkne.

Jeden konkrétní případ stojí za to znát, protože právě kvůli němu se z „vyčistil jsem a nepomohlo to“ obvykle stane „smazal jsem DerivedData a pomohlo to“: mezipaměť předkompilovaných modulů (ModuleCache.noindex) leží v kořeni DerivedData, ne v podsložce některého projektu. Clean Build Folder se k ní nikdy nedostane. Když mezipaměť modulů po změně SDK nebo toolchainu zastará, chybu odstraní jen její smazání.

Ani jeden z příkazů neopraví skutečnou chybu ve vašem kódu nebo v závislostech. Pokud stejná chyba přetrvá i po sestavení načisto, přestaňte čistit a přečtěte si hlášení kompilátoru – příčina je v nastavení projektu, v Package.resolved, ve vybraném SDK nebo přímo v kódu.

Ani jedno není způsob, jak uvolnit místo na disku

Clean Build Folder je diagnostický nástroj, který mimochodem uvolní trochu místa. U aktuálního projektu může nějaké místo vrátit, ale produkty sestavení všech ostatních projektů, všechny indexy i mezipaměť modulů zůstanou přesně tam, kde byly. Spouštět ho kvůli místu na disku se míjí účinkem.

Pokud vám jde opravdu o místo, postupujte opačně: nejdřív změřte podsložky v DerivedData a pak smažte ty, které patří projektům, jež jste měsíce neotevřeli. Tam se obvykle skrývají desítky gigabajtů – jednorázové klony, které jste jednou sestavili a už se k nim nevrátili.

Nezačínejte příkazem rm -rf. Ve Finderu můžete vybrané složky přesunout do Koše, odkud je lze obnovit, dokud ho nevysypete – a ten rozdíl oceníte hned poprvé, když smažete složku projektu, který se zrovna sestavuje. Terminál se vyplatí pro automatizaci, ale až po ověření přesné cesty.

Výsledek si ověřte, nespoléhejte na čísla

Než cokoli uděláte, zapište si velikost DerivedData, použijte právě jednu z obou možností a velikost změřte znovu. Po Clean Build Folder sestavte aktuální schéma. Po smazání složky v DerivedData otevřete Xcode a počkejte, až doběhne první sestavení a indexování.

Díky tomuto pořadí oddělíte získané místo od ceny, kterou jste za něj zaplatili. Univerzální číslo, se kterým by se dalo počítat, neexistuje: výsledek závisí na tom, kolik projektů, konfigurací a architektur se na daném Macu sestavovalo.

Kdy sáhnout po které možnosti

Tabulka popisuje rozsah zásahu, ne slibovaný počet gigabajtů. Změřte svůj Mac před zásahem i po něm.

Časté dotazy