人們喜歡討厭構建系統。 僅僅觀看 CppCon17 上的演講,就能夠看到開發人員由於構建系統而鬧笑話的例子。 這讓咱們思考一個問題:爲何會這樣? 構建系統時固然不可能天衣無縫。 但我認爲,在 2018 年,咱們能夠很好地解決其中的一些問題。 這就是 CMake。不過 CMake 2.8 可能不行; 它在 C++11 發佈以前就 release 了! 對於 CMake 來講也沒有可怕的例子(甚至那些發佈在 KitWare 本身的教程列表中的例子)。 咱們來談論現代 CMake。CMake 3.1+,甚至多是 CMake 3.15+! 它整潔,強大,優雅,所以你能夠將大部分時間花在編碼上,而不是編寫不可讀,不可維護的 Make(或CMake 2)文件。 固然,CMake 3.11+ 運行起來也應該明顯更快!git
簡而言之,若是你在考慮使用現代 CMake,這些多是你最關心的問題:安全
下面哪幾點適合你?網絡
若是是這樣,你將受益於相似 CMake 的構建系統。ide
構建系統是一個熱門話題。 固然你們有不少選擇。但即便是很是好的,或者重用一個熟悉的語法,也沒法和 CMake 相提並論。 爲何?生態支持。 每一個 IDE 都支持 CMake(或 CMake 支持這些 IDE)。 有更多的軟件包在使用 CMake 而不是其餘構建系統。 所以,若是你在使用一個軟件包,它被設計爲包含在你的代碼中,你能夠選擇:建立本身的構建系統,或使用一個它支持的構建系統:這些軟件包幾乎老是支持 CMake。 若是你要使用多個軟件包,CMake 將很快成爲共同點。 並且,若是你須要一個預安裝軟件包,那麼它有 CMake 查找或配置腳本的可能性很是高。wordpress
大約 CMake 2.6-2.8 的時候,CMake 開始流行起來。出如今了大多數 Linux 操做系統的軟件包管理器列表中,而且被用於許多軟件包使用。 而後 Python 3 問世了。 我知道,這與 CMake 沒有任何關係。 但它是第三版。 它前面有一個第二版: 這是一個艱難,醜陋的過渡,即便在今天,一些軟件仍然還在使用第二版。工具
我相信 CMake 3 運氣不會比 Python 3 好到哪兒去。1 儘管每一個版本的 CMake 都是努力向後兼容,但 CMake 3 系列任然被視爲新東西。 所以,你會發現操做系統,像 CentOS 7,已經擁有 GCC 4.8,幾乎徹底支持 C++ 14,還在使用在 C++ 11 以前就推出的 CMake 2.8。gitlab
你真的至少應該使用編譯器發佈以後出現的 CMake 版本,由於構建系統須要知道新版本編譯器的編譯標誌等信息。 並且,因爲 CMake 會將本身退化爲 CMake 文件中指示的所需的最低版本,所以,即便你在系統範圍內安裝一個新的 CMake,也是很是安全的。 或者你至少應該在本地安裝它。 這很容易 (大多數狀況下也就一兩行代碼的事兒), 你會發現 5 分鐘的工做將爲你節省數百行和幾小時的 CMakeLists.txt
編寫時間,而且從長遠來看將更容易維護。 本書試圖解決那些網絡上隨處可見的糟糕問題和例子,以及提出最佳實踐的方法。ui
在網上還有一些其餘地方能夠找到有用的信息。下面是其中的一些:編碼
現代 CMake 最初由 Henry Schreiner 編寫。其餘貢獻者信息能夠 GitLab 項目貢獻者列表 中找到。
1. CMake 3.0 還從很是舊版本的 CMake 中刪除了幾個長期棄用的功能,並對與方括號相關的語法作了一個很是微小的向後不兼容的更改,因此這不徹底公平; 可能會有一些很是很是古老的 CMake 文件在 CMake 3+ 中不能運行;雖然我歷來沒有見過。 ↩