在了解xcode構(gòu)建原則之前，需要熟悉workspace相關(guān)的概念，即workspace,project和target

target

target指定了構(gòu)建的product,包含將workspace或project中的一組文件構(gòu)建成product的指令。單個target定義一個product,它將輸入（源文件和處理這些源文件的指令（包含所設(shè)定的構(gòu)建settings和phases））組織進(jìn)構(gòu)建系統(tǒng)中。project和target是一對多的關(guān)系。

target會繼承project的build settings，但可以以target為粒度設(shè)置build settings,且Xcode中當(dāng)前一次只會有一個有效target,此有效target在xcode scheme中標(biāo)識。

若target A依賴target B的輸出來構(gòu)建，則A依賴B，當(dāng)它們存在于一個xcode workspace中的時候，Xcode會發(fā)現(xiàn)此依賴關(guān)系并按順序構(gòu)建。這種依賴稱為隱性依賴，當(dāng)然也可以在build settings中聲明顯性依賴，也可將隱性依賴的兩個target顯性聲明為沒有依賴。比如可能在同一個workspace中同時構(gòu)建一個庫并構(gòu)建一個依賴這個庫的應(yīng)用，則xcode會選擇先構(gòu)建庫。但如果應(yīng)用想鏈接庫的某個特定版本，則可以顯性聲明這個依賴關(guān)系，此時隱性依賴即被覆蓋了。

project

xcode project是存儲構(gòu)建一個或多個軟件產(chǎn)品所需的所有文件，資源和信息的倉庫。project包含構(gòu)建product所需的所有要素并維護(hù)它們之間的關(guān)系，它包含一個或多個targets(target指定了構(gòu)建product的方式)。project定義了所有target的默認(rèn)build settings，各target可以重載。

Xcode project文件包含如下信息：

源文件的引用：源代碼（包括頭文件和實現(xiàn)文件），library和framework(xcode內(nèi)部或者外部),資源文件，interface builder文件

文件結(jié)構(gòu)列表中組織源文件的Groups

project級別的build選項

targets

debug或測試program的可執(zhí)行環(huán)境：從xcode運(yùn)行或調(diào)試時啟動哪些可以執(zhí)行文件，傳給可執(zhí)行文件的命令行參數(shù)，程序運(yùn)行時設(shè)置的環(huán)境變量

總之，project可以單獨存在也可以包含在workspace中，同時可以在Scheme中指定哪個Target、build配置、哪個可執(zhí)行配置在某個時刻是有效的。

build settings

一個build setting是一個指示產(chǎn)品某個方面構(gòu)建方式的變量，比如決定xcode傳給編譯器的參數(shù)選項是怎樣。其是一個常量或者一個公式供給xcode在構(gòu)建的時候計算build setting。

workspace

workspace 是組織projects和其他協(xié)同工作的文檔的一份文檔。除此之外，它還維護(hù)project和target之間的顯性及隱性的依賴關(guān)系。

默認(rèn)workspace中的所有Xcode projects都在同一個目錄下構(gòu)建，稱為workspace build directory，由于所有project的所有文件都在同一個目錄下，所以所有文件都對每個project可見。比如兩個project使用同一個庫，則不用復(fù)制到另一個project目錄中。

workspace中的每個project都有其獨立id,同時project可以屬于多個workspace，可以單獨打開project或者在其他workspace中打開，且都不用重新配置project或者workspace。

可以使用workspace默認(rèn)的build 目錄，也可以指定一個。如果project指定了構(gòu)建目錄，這個目錄會被project構(gòu)建時所在的workspace的build目錄覆蓋。

xcode scheme

xcode scheme定義了一系列構(gòu)建的targets，構(gòu)建時的配置，和一系列執(zhí)行的測試。

可以有很多scheme,但同一時刻只能有一個有效的。選擇scheme時，意味著你也選擇了一個運(yùn)行目標(biāo)（product構(gòu)建的硬件平臺)。可以指定scheme是否存儲在project中，以便包含此project的所有workspace都可以使用些scheme,當(dāng)然也可以指定只存儲在某個workspace中。

現(xiàn)實案例

如果需要將project A的輸出*.a作為project B的輸入，則可以在B的framework中添加A的project文件。此時project A的內(nèi)容即可在B的framework層級中展開，同時為了使用A中的頭文件，需要將其源文件路徑加入A中的target的Build Settings中的User Header Search Paths中

而將所使用的庫的頭文件及*.a文件配置進(jìn)spec文件中，并將其交付給pod管理的情況，則由pod默認(rèn)將頭文件均添加進(jìn)了Pod目錄 Pods/Headers/Public中，并將此目錄配置進(jìn)了Pods target的Header Search Paths中

pods管理的各個庫的頭文件導(dǎo)入的方式

而.a文件導(dǎo)入的方式則是通過如下配置選項來完成

pod管理的項目直接配置的.a文件導(dǎo)入項目的方式

依賴的project依賴了同樣的pod庫

如果project B所依賴的project A需要依賴同樣的Pod庫，則情況會復(fù)雜一些，首先是，在Podfile文件中，如果添加兩條xcodeproj指令

添加兩條xcodeproj指令的Podfile

則會導(dǎo)致在執(zhí)行pod update命令時，頭一條xcodeproj 指令所 指明的proj無法被pod所找到

添加了兩條xcodeproj

而如果將A作為B的exclusive target，則A和B在workspace中的關(guān)系會是平級的關(guān)系，所以Podfile中不需要添加project A的信息，只需要將A作為 B所依賴的framework導(dǎo)入進(jìn)來即可。由于project A由于整個項目位于B中，所以Podfile.lock相對于其目錄的位置會不一樣，有可能出現(xiàn)Check Pods Manifest.lock中所執(zhí)行的

diff指令中 Podfile.lock文件路徑不正確的總是，這時需要手動調(diào)整

如果只讓A依賴pod庫，同時B也依賴pod庫，則會出現(xiàn)多重符號的提示

當(dāng)然，如果能夠讓A和B都可以自由地依賴各自所依賴的Pod庫自然是最好，但目前還未發(fā)現(xiàn)同一個workspace中想到依賴的xcodeproj同時依賴同一個pod庫的解決方案