Xcode 4: co je to Workspace? - MujMAC.cz - Apple, Mac OS X, Apple iPod

26. října 2011, 00.00 | Než opustíme sérii článků o práci v prostředí Xcode a pustíme se opět do programování, zbývá dokončit několik drobností, o nichž jsme se dříve sice zmínili, ale nezabývali jsme se jimi podrobněji. Dnes se podíváme na "Workspaces".

Jak jsme si řekli v dílu, věnovaném základům projektů v Xcode, již hodně dávno programátoři zjistili, že je často praktické pracovat nad "několika projekty", jež spolu úzce souvisí – a mnohdy i sdílejí některé zdrojové texty – zároveň. Typickým případem může být třeba knihovna služeb, pak testovací kód pro ověření správnosti této knihovny, a konečně pak aplikace, jež služeb knihovny využívá. ... V Xcode tradičně pro tyto účely slouží tzv. "cíle" ... Xcode 4 nabízí alternativní možnost "sdružování projektů", tzv. Workspaces. Dnes nastal čas, abychom se na "workspaces" podívali trochu blíže.

Co to tedy je?

Základ je velmi jednoduchý: workspace je prostě víceméně libovolná skupina projektů; skoro nic více (může zde být ještě uloženo nějaké nastavení) a nic méně.

Z "technického" pohledu je workspace prostě soubor s příponou ".xcworkspace" (jedná se – jak je v Mac OS X obvyklé – o package, tedy ve skutečnosti o složku, která je ale ve Finderu vždy reprezentována jako soubor a pracuje se s ní vždy jako s celkem). Tento soubor může být uložen kdekoli na disku, a může obsahovat odkazy na projekty, jež samy leží také kdekoli na disku (a nějaká nastavení).

Workspace se tedy velmi podobá projektu v nejužším smyslu slova, totiž souboru ".xcodeproj", který obsahuje odkazy na soubory projektu a řadu nastavení. Na rozdíl od projektu ale workspace není implicitně spojeno s žádnou složkou: zatímco složka, v níž leží soubor .xcodeproj, je téměř vždy dedikována pro projekt, obvykle neobsahuje nic, co by s projektem úzce nesouviselo (a často ji pro zjednodušení i "projektem" nazýváme), složka, v níž je uložen soubor .xcworkspace, žádné význačné postavení nemá.

Rozdíly jsou vlastně jen dva:

• zatímco projekt může obsahovat (odkazy na) libovolné soubory, workspace může obsahovat pouze odkazy na projekty;

• zatímco projekt může obsahovat dlouhou řadu nejrůznějších nastavení, workspace obsahuje pouze tzv. schémata (zběžně jsme se s nimi seznámili hned v úvodním dílu, věnovaném Xcode 4; podrobný popis schémat nás dosud čeká), plus uživatelská nastavení typu "velikost okna" apod.

A k čemu je to tedy dobré?

Účelem workspaces je sdružovat dohromady projekty, jež spolu do jisté míry souvisí; nejde ale o tak úzkou souvislost, aby se vyplatilo je realizovat jako různé cíle jediného projektu. V praxi nejspíše půjde o projekty, jež mohou být sdíleny mezi více různými workspaces – např. vlastní knihovna univerzálních služeb, již používáme pro většinu aplikací, může být s projekty, obsahujícími tyto aplikace, sdílena pomocí řady workspaces, zhruba nějak takto:

Projekty
  Knihovna
    Knihovna.xcodeproj
      (obsahuje mj. odkazy na níže uvedené soubory)
    Knihovna.h
    Knihovna.m
    ... a další zdrojové soubory ...
  Aplikace1
    Aplikace1.xcodeproj
      (obsahuje mj. odkazy na níže uvedené soubory)
    main.m
    AppDelegate.h
    AppDelegate.m
    ... a další zdrojové soubory ...
  Aplikace2
    Aplikace2.xcodeproj
      (obsahuje mj. odkazy na níže uvedené soubory)
    main.m
    AppDelegate.h
    AppDelegate.m
    ... a další zdrojové soubory ...
  Aplikace1.xcworkspace
    (odkazy na projekty Knihovna.xcodeproj a Aplikace1.xcodeproj)
  Aplikace2.xcworkspace
    (odkazy na projekty Knihovna.xcodeproj a Aplikace2.xcodeproj)

Xcode zajišťuje automaticky řadu služeb, jež do jisté míry takto sdružené projekty propojují a usnadňují jejich spolupráci; speciálně se jedná o následující:

• složky, obsahující generovaná data (indexy, výsledky překladu apod.), o nichž jsme se bavili minule, jsou sdíleny všemi projekty ve workspace;

• tedy jsou sdílené i indexy, a je možné využívat služby jako vyhledávání, kontextově závislé doplňování nebo refactoring nad všemi projekty z workspace najednou;

• Xcode automaticky detekuje závislosti mezi projekty – tedy např. linkování aplikace proti výsledku sestavení knihovny – a na jejich základě samo sestaví nejprve projekty, na nichž závisí ostatní, aniž bychom tyto závislosti museli explicitně určit.

Jak workspace sestavit?

Základní služba pro vytvoření nového Workspace je "File / New / New Worskpace..." Máme-li workspace otevřené, můžeme

• do něj přidat libovolný projekt vhozením souboru .xcodeproj do volného místa v Navigátoru (pozor – volné místo je důležité: pokud bychom jej vhodili mezi ikonky souborů některého z projektů, jež už ve workspace jsou, přidali bychom jej do toho projektu a nikoli do workspace samotného);

• nebo přidat libovolný projekt pomocí služby "Add Files...";

• nebo vytvořit nový projekt službou "File / New / New Project..." – projekt se standardně vytvoří a hned se (odkaz na něj) uloží do workspace.

Problémy

Bohužel, podle mých zkušeností je s workspaces řada problémů, jejichž vinou je – přinejmenším v iOSu, kde nelze ani pracovat se sdílenými dynamickými knihovnami, ani tam nelze spouštět pomocné programy – v praxi většinou jednodušší prostě sdílet přímo zdrojové soubory mezi více projekty, než využívat workspaces.

Mezi problémy, s nimiž jsem se setkal, patří

• ne zcela spolehlivá automatická detekce závislostí – přinejmenším v Xcode 4.0 bylo občas zapotřebí sdílenou knihovnu přidat znovu, aby se odpovídající projekt automaticky sestavil a neohlásila se jen chyba "není knihovna";

• problém s importem – hlavičkové soubory knihoven nejsou automaticky k dispozici pro aplikace v témže workspace, a to ani dáme-li si pozor na to, abychom je v inspektoru označili jako "public". Řada programátorů to řeší sdílením hlavičkových souborů mezi projekty (pak ovšem se efekt workspace celkem ztrácí); asi nejlepší řešení, o němž vím, je v nastavení ("Build Settings") projektu každé knihovny, jež má být používána v nějakém workspace, nastavit "Public Headers Folder Path" na "/include";

• problémy s kategoriemi: zde nejde ani tak o chybu workspaces, ale o obtíž při linkování proti statickým knihovnám. Linker totiž má tendenci kategorie tiše ignorovat a nezahrnout je do výsledné aplikace (může za to optimalizace "odstranit nepoužitý kód"). Řešení je poměrně složité; vinou chyby v linkeru je zapotřebí (a) přidat přepínač -ObjC do nastavení "Other Linker Flags" knihovny, (b) přidat přepínač -all_load do téhož nastavení aplikace (vizte podrobnosti např. zde)...

• ... a nakonec hlavní problém, jehož řešení přinejmenším v Xcode 4.0 neznám: změny ve zdrojových souborech knihovny nejsou automaticky detekovány pro nové sestavení závislého projektu ve workspace :( Je tedy nutné ručně přepnout cíl v rozevírací nabídce v levém horním rohu na knihovnu, tu sestavit, přepnout zpět na aplikaci, a sestavit i ji: to ovšem už opravdu stejně dobře můžeme používat dva samostatné projekty.