為何選擇 CMake?

如果您曾經維護過軟體套件的建置和安裝流程,您將會對 CMake 感興趣。CMake 是一個開源的軟體專案建置系統產生器,它允許開發人員以簡單、可攜的文字檔案格式指定建置參數。CMake 接著會使用這個檔案,為原生建置工具(包括整合開發環境 (IDE),例如 Microsoft Visual Studio 或 Apple 的 Xcode,以及 UNIX、Linux、NMake 和 Ninja)產生專案檔。CMake 以簡單的方式處理軟體建置的困難之處,例如跨平台建置、系統自我檢查和使用者自訂建置,讓使用者可以輕鬆地為複雜的硬體和軟體系統量身打造建置。

對於任何專案,尤其是跨平台專案,都需要一個統一的建置系統。許多非基於 CMake 的專案同時包含 UNIX Makefile(或 Makefile.in)和 Microsoft Visual Studio 工作區。這需要開發人員不斷嘗試使這兩個建置系統保持最新且彼此一致。為了鎖定其他建置系統(例如 Xcode),需要更多這些檔案的自訂副本,這會產生更大的問題。如果您嘗試支援可選元件,例如在系統上提供 libjpeg 時包含 JPEG 支援,則此問題會更加複雜。CMake 通過將這些不同的操作整合到一個簡單易懂的檔案格式中來解決此問題。

如果有多位開發人員在一個專案上工作,或者有多個目標平台,那麼該軟體將必須在多台電腦上進行建置。鑑於設定現代電腦所涉及的各種已安裝軟體和自訂選項,在同一作業系統上運行的兩台電腦很可能略有不同。CMake 為單一平台、多機器開發環境提供了許多好處,包括

  • 能夠自動搜尋正在建置的軟體可能需要的程式、函式庫和標頭檔。這包括在搜尋時考慮環境變數和 Windows 登錄設定的能力。

  • 能夠在來源樹之外的目錄樹中進行建置。這是許多 UNIX 平台上的一個實用功能;CMake 在 Windows 上也提供了此功能。這允許開發人員移除整個建置目錄,而無需擔心移除原始碼檔案。

  • 能夠為自動產生的檔案建立複雜的自訂命令,例如 Qt 的 moc() 或 SWIG 包裝函式產生器。這些命令用於在建置過程中產生新的原始碼檔案,然後將這些檔案編譯到軟體中。

  • 能夠在設定時選擇可選元件。例如,VTK 的幾個函式庫是可選的,CMake 為使用者提供了一種簡單的方法來選擇要建置的函式庫。

  • 能夠從一個簡單的文字檔自動產生工作區和專案。這對於擁有許多程式或測試案例的系統來說非常方便,每個程式或測試案例都需要一個單獨的專案檔,通常使用 IDE 建立是一個繁瑣的手動過程。

  • 能夠輕鬆地在靜態建置和共享建置之間切換。CMake 知道如何在所有支援的平台上建立共享函式庫和模組。它會處理複雜的平台特定連結器標記,並且在許多 UNIX 系統上支援用於共享函式庫的內建執行階段搜尋路徑等進階功能。

  • 在大多數平台上自動產生檔案相依性並支援平行建置。

在開發跨平台軟體時,CMake 提供了許多額外功能

  • 能夠測試機器位元組順序和其他硬體特定特性。

  • 一組可在所有平台上運作的建置設定檔。這避免了開發人員必須在專案內以幾種不同格式維護相同資訊的問題。

  • 支援在所有支援的平台上建置共享函式庫。

  • 能夠使用系統相關資訊設定檔案,例如資料檔和其他資訊的位置。CMake 可以建立標頭檔,其中包含諸如資料檔路徑和其他資訊,其形式為 #define 巨集。系統特定標記也可以放在已設定的標頭檔中。這比編譯器的命令列 -D 選項更有優勢,因為它允許其他建置系統使用 CMake 建置的函式庫,而無需指定建置期間使用的完全相同的命令列選項。

CMake 的歷史

自 1999 年以來,CMake 一直在積極開發中,並且已經成熟到足以成為各種建置問題的成熟解決方案。CMake 的開發始於美國國家醫學圖書館資助的 Insight Toolkit (ITK) 的一部分。ITK 是一個大型軟體專案,可在多個平台上運作,並且可以與許多其他軟體套件互動。為了支援這一點,需要一個功能強大但易於使用的建置工具。在過去使用大型專案的建置系統之後,開發人員設計了 CMake 來滿足這些需求。從那時起,CMake 的受歡迎程度持續增長,許多專案和開發人員都因其易用性和靈活性而採用它。最能說明這一點的例子是 CMake 作為 K 桌面環境 (KDE) 的建置系統的成功採用,KDE 可以說是現存最大的開源軟體專案。

CMake 還以 CTest 的形式包含軟體測試支援。測試軟體的一部分過程包括建置軟體、可能安裝軟體,以及確定軟體的哪些部分適合目前的系統。這使得 CTest 成為 CMake 的邏輯延伸,因為它已經擁有大部分資訊。類似地,CMake 包含 CPack,旨在支援軟體的跨平台發佈。它提供了一種跨平台方法來為您的軟體建立原生安裝,利用現有的流行套件,例如 WiX、RPM、Cygwin 和 PackageMaker。

CMake 會持續追蹤並支援可用的流行建置工具。CMake 迅速為 Microsoft Visual Studio 和 Apple 的 Xcode IDE 的新版本提供了支援。此外,還為 CMake 新增了來自 Google 的新建置工具 Ninja 的支援。透過 CMake,一旦您編寫了輸入檔案,您就可以免費獲得對新編譯器和建置系統的支援,因為對它們的支援已內建在 CMake 的新版本中,而不是與您的軟體發佈綁定。CMake 還持續支援交叉編譯到其他作業系統或嵌入式裝置。在交叉編譯時,CMake 中的大多數命令都能正確處理主機系統和目標平台之間的差異。

為何不使用 Autoconf?

在開發 CMake 之前,其作者已經擁有使用現有可用建置工具的經驗。Autoconf 與 Automake 結合使用,可提供與 CMake 相同的一些功能,但在 Windows 平台上使用這些工具需要安裝許多 Windows 原生沒有的其他工具。除了需要大量工具外,autoconf 可能難以使用或擴充,而且無法執行 CMake 中容易執行的一些任務。即使您確實讓 autoconf 及其所需的環境在您的系統上執行,它也會產生強迫使用者使用命令列的 Makefiles。另一方面,CMake 提供了一個選擇,讓開發人員產生可以直接從 Windows 和 Xcode 開發人員習慣的 IDE 使用的專案檔。

雖然 autoconf 支援使用者指定的選項,但它不支援相依選項,其中一個選項相依於另一個屬性或選擇。例如,在 CMake 中,您可以有一個使用者選項,讓多執行緒相依於首先確定使用者的系統是否支援多執行緒。CMake 提供了一個互動式使用者介面,讓使用者可以輕鬆查看哪些選項可用以及如何設定這些選項。

對於 UNIX 使用者,CMake 還提供自動相依性產生,而 autoconf 並未直接完成。CMake 的簡單輸入格式也比 Makefile.in 和 configure.in 檔案的組合更易於閱讀和維護。CMake 能夠記住和鏈結函式庫相依性資訊,這在 autoconf/automake 中沒有等效的功能。

為何不使用 JAM、qmake、SCons 或 ANT?

其他工具,例如 ANT、qmake、SCons 和 JAM,已經採用不同的方法來解決這些問題,它們幫助我們塑造了 CMake。在這四個工具中,qmake 與 CMake 最相似,儘管它缺少 CMake 提供的大部分系統自我檢查功能。qmake 的輸入格式與傳統的 Makefile 更相似。ANT、JAM 和 SCons 也是跨平台的,儘管它們不支援產生原生專案檔。它們確實擺脫了傳統的以 Makefile 為導向的輸入,ANT 使用 XML;JAM 使用自己的語言;而 SCons 使用 Python。其中一些工具直接執行編譯器,而不是讓系統的建置程序執行該任務。其中許多工具需要安裝其他工具(例如 Python 或 Java)才能運作。

為何不自己編寫腳本?

一些專案使用現有的腳本語言(例如 Perl 或 Python)來設定建置程序。雖然可以使用類似的系統實現類似的功能,但過度使用這些工具可能會使建置程序更像是尋找復活節彩蛋,而不是一個簡單易用的建置系統。在建置您的軟體套件時,使用者必須先找到並安裝 4.3.2 版的這個和 3.2.4 版的那個,然後才能開始建置程序。為了避免這個問題,決定 CMake 需要的工具不會比它用於建置的軟體需要的工具多。至少,使用 CMake 需要一個 C 編譯器、該編譯器的原生建置工具和一個 CMake 可執行檔。CMake 是用 C++ 編寫的,只需要一個 C++ 編譯器來建置,並且大多數系統都提供預編譯的二進位檔。自己編寫腳本通常也意味著您不會產生原生 Xcode 或 Visual Studio 工作區,這使得 Mac 和 Windows 建置受到限制。

CMake 在哪些平台上執行?

CMake 在各種平台上執行,包括 Microsoft Windows、Apple Mac OS X 和大多數 UNIX 或類 UNIX 平台。同樣,CMake 支援大多數常見的編譯器。

CMake 的穩定性如何?

在為專案採用任何新技術或工具之前,開發人員會想知道該工具的支援程度和受歡迎程度。自最初的 CMake 實作以來,CMake 作為建置工具的受歡迎程度不斷提高。開發人員和使用者社群都在持續成長。CMake 一直在開發對新建置技術和工具的支援。CMake 開發團隊對向後相容性做出了堅定的承諾。如果 CMake 可以建置您的專案一次,它應該始終能夠建置您的專案。此外,由於 CMake 是一個開源專案,因此專案的原始碼始終可供編輯和修補。