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

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

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

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

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

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

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

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

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

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

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

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

[提高代碼可讀性]

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

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

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

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

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

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

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

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

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

[方便部署]

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

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

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

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

總結

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

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