大部分人都至少接觸過不止一種構建工具，比如make，autotools。而我們開發了Blade，為什么那么多現成的工具不用，而又再造了一個輪子，相對于傳統的make等工具，Blade的好處在又哪里呢？你的項目是否適合用Blade來構建，

以前的文檔都是冷冰的介紹，今天本文將從作者和開發人員以及項目代碼維護者的角度回答這些問題。

Blade總的來說要解決這些問題：

真正環境下的C++軟件的開發，往往有數十人甚至數百個開發人員，源代碼有成千上萬個文件，百萬甚至千萬行。如何高效而安全地構建這些代碼？

為了保證代碼質量，我們還需要Codereview，代碼提交流程，自動檢測工具，單元測試，持續集成等現代化的開發流程，如何保證這些流程被實施？
Blade就是為這樣的項目而生的。

下面是我分析的Blade的特點：

[構建規則簡單]
Blade的構建規則很簡單，是說明性而非指令性的，只要描述出源文件以及依賴即可，不需要描述如何構建。我比較過gyp和cmake的構建規則，都不如blade的簡潔。

因為描述的是需要什么而不是怎么做，因此不需要開發人員掌握gcc的命令行，更無需記憶make的哪些奇奇怪怪的自動變量，大幅度降低使用門檻。

Blade還直接支持編譯 protobuf，lex, yacc, swig 等，不需要自己寫構建命令和規則。

[自動依賴分析和傳遞]
用過Make的都知道，所有的依賴關系要自己維護。我們都知道C/C++語言中的頭文件是個很麻煩的事情，
在手工維護的make的依賴規則中，一般只寫出.o文件對.c文件的依賴，這樣當.c文件所包含的頭文件變化時，
不會自動構建，這時候往往是需要做一次make clean然后重新編譯，用make維護增量構建的意義大減。
即使寫了對頭文件的依賴，但是頭文件里還會包含頭文件，對于這些間接包含的頭文件，是多到無法寫出的。

而Blade自動分析頭文件依賴關系，構建受影響的代碼。頭文件變化時，所有直接和間接包含它的源文件都會
被自動找出來，進行構建。而不受影響的源文件則無需重復構建，真正實現了增量構建。對于鏈接也是一樣。

對于大的項目，我們往往分成多個庫來構建，而且庫之間還會有依賴關系，如果用了一個庫，在用make的時候，
我們需要在命令行把它依賴的庫都列出來，一個都不能少，而且順序還不能錯，否則都會導致鏈接錯誤。
更麻煩的是，假如某個庫的實現變了，不再增加了一個新的依賴，那么所以用到這個庫的地方都需要修改加上這個依賴。
Blade只需要開發人員寫出直接依賴，而庫的間接依賴是自動分析出來的，構建時也會自動檢查所依賴的庫是否需要重新構建。

[提高代碼可讀性]

既然Blade的構建理念是把整個項目看作一個有機的整體，那么頭文件和庫文件都在這個項目中有唯一的位置，天然不會重復，不怕重名。我多次經歷或者見過頭文件或者庫文件重名，每次都浪費大量的時間。

Blade提倡從項目根目錄開始定位文件和庫，徹底避免了這樣的問題。在這樣方式組織代碼的項目工作越久，就越能體會到Blade提倡的#include 從根開始寫是在保護你而不是在故意為難你，并開始喜歡這種組織方式。

[構建速度優化]
除了上面所說的依賴關系維護消除了clean使得只需要增量構建外，Blade還開啟了并行構建，默認多個進程同時構建，提高構建速度。
對于make也不是不可以并行構建，但是由于依賴關系的負責性，更容易出錯。
為了進一步提高構建速度，Blade還支持ccache緩存構建結果和distcc分布式構建。

[易用性]
持續集成是代碼質量的有效保證。通過持續集成，使代碼持續處于可構建狀態，大幅度減少了錯誤，提高了發布和部署的效率。
在做發布和持續集成時，我們常需要一次構建所有的目標，有時候還需要涉及32位64位等多個平臺。
用make時一般的做法是用遞歸make，在上層的makefile里描述出有哪些子目錄，并層層遞歸。這樣的缺點是，
底層目錄改動需要修改上層的Makefile，再加上庫的依賴不能傳遞，使得makefile維護的大項目經常處于無法完整成功構建的狀態。

Blade支持一下子構建整個目錄樹，并不需要寫額外的描述。

對于遞歸make，兩個目錄有依賴關系時，依賴者就無法單獨構建，需要跑到上層目錄，先構建依賴，再構建自己才行。否則可能會用到舊的庫。
Blade在代碼樹的任意子目錄下都能構建，其依賴會被自動找出來構建，不多不少，確保正確性。

Blade內置 debug/release 兩種構建類型，32/64位兩種目標平臺。

Blade的構建進度顯示被大幅度簡化為做了什么而不是在怎么做，減少了make中默認顯示出的完整命令行對視覺的干擾。
為了更醒目地發現問題，構建過程中的警告和錯誤信息是用彩色高亮現實的，一眼就能看到錯誤提示行。

Blade的命令行接口類似svn，由一系列子命令，目標名和參數組成，簡單好記憶，還支持bash風格的命令行補全，按tab鍵自動補全命令行。

[方便部署]

在我看來動態庫就是災難，見過不少依賴dlopen加載的庫/框架，有的還支持熱卸載，甚至想在同一個進程中加載不同版本的兩個庫來做對比測試，這樣的項目無不bug不斷，開發人員痛苦不堪。

因此Blade提倡靜態鏈接，默認甚至把libstdc++和libgcc都靜態鏈接到了可執行文件。發布時一個可執行文件就搞定（可能還需要一些配置文件，數據文件等）。省時省心。

[測試支持]
單元測試是代碼質量的重要保證，可以把大量的低級錯誤消滅在萌芽狀態，并提高代碼的可維護性，降低開發成本。
用make的時候，一般是寫一些可執行文件類型的目標，構建出來后，在人工運行它，沒有任何機制保證這些測試會被運行。
如果測試寫了不運行就等于白寫，Blade直接支持類型為測試的目標類型，只需要描述哪些目標是是測試即可。Blade支持命令行批量執行這些測試。
因此運行測試可以由開發人員主動進行，也可以通過開發流程工具，在代碼發起review或者提交前運行，以及持續集成時運行，使得測試真正做起來。
為了提高測試效率，自動支持多個測試進程并發運行，支持增量測試（自動跳過最后一次是成功且沒有新的變化的測試程序）。
為了檢查內存泄露，測試集成 gperftools，自動檢測測試程序的內存泄露，使得大部分內存泄露可以在單元測試時發現。

最后總結一下，Blade是為了減輕大規模C++項目的維護成本，提高開發效率和質量而生的現代化構建工具。

總結

以上是生活随笔為你收集整理的Blade和其他构建工具有什么不同的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。