Bazel是一個支持多語言、跨平臺的構(gòu)建工具。Bazel支持任意大小的構(gòu)建目標(biāo)，并支持跨多個倉庫的構(gòu)建，是Google主推的一種構(gòu)建工具。

優(yōu)勢

Bazel存在如下方面的優(yōu)勢。

• 易理解：Bazel對外提供聲明式表達(dá)的構(gòu)建DSL，可讀性好，降低了構(gòu)建系統(tǒng)的實現(xiàn)復(fù)雜度；
• 速度快：得益于Bazel優(yōu)異的編譯緩存和依賴分析技術(shù)，更好地支持并行和增量編譯，甚至增量測試；
• 跨平臺：一套構(gòu)建系統(tǒng)，支持多平臺，異構(gòu)系統(tǒng)的構(gòu)建；
• 可擴(kuò)展：使用類Python語言(Starlark)擴(kuò)展規(guī)則，支持多語言構(gòu)建；
• 大規(guī)模：支持100k+源文件規(guī)模的構(gòu)建，支持多倉的依賴管理；
• 云構(gòu)建：天然地支持云構(gòu)建，復(fù)用既有的計算資源。

舉個例子，使用Bazel，工程中如果需要自動生成Protobuf代碼，配置CUDA編程環(huán)境，管理多倉代碼的依賴等，Bazel相對具有明顯的優(yōu)勢。

劣勢

但是，Bazel也存在一些與生俱來的缺陷。

Bazel運行于JRE

也就是說，安裝Bazel需要額外安裝JRE，即使Bazel二進(jìn)制包內(nèi)嵌了一個最小化的JRE；此外，Bazel啟動速度遲鈍，內(nèi)存消耗很厲害。

業(yè)界存在其他構(gòu)建工具，例如Scons，它使用Python。但是，在幾乎所有的Unix開發(fā)環(huán)境中，Python是預(yù)裝的，這給開發(fā)者減少了很大麻煩。

所以，Native風(fēng)格的構(gòu)建工具具有很大的競爭優(yōu)勢。一方面，安裝極簡，用戶心智負(fù)擔(dān)不大；另一方面，用戶不需要額外安裝依賴，整個工具鏈的安裝是完備的、閉包的。

Bazel與Unix社區(qū)文化存在沖突

在Unix社區(qū)，開發(fā)者已然非常熟悉./configure, make, make install的構(gòu)建工作流，及其相關(guān)的工具鏈。而且，開發(fā)者一致遵循FHS(文件系統(tǒng)層次標(biāo)準(zhǔn))的約定。

但是，Bazel改變了Unix一貫的風(fēng)格和文化，與社區(qū)文化產(chǎn)生了劇烈的矛盾。如果你使用Bazel發(fā)布一個庫，對不起，你的用戶也得用Bazel，才能引用到你的庫。Bazel不支持類似于bazel install命令，你的用戶只能使用Bazel，然后創(chuàng)建新的規(guī)則去依賴你的庫。使用Bazel，你強(qiáng)奸了你的用戶群。

反過來，如果Bazel要想依賴于一個非Bazel的庫，得做適配才能使用，用戶不能復(fù)用既有存在的CMake或Make的構(gòu)建系統(tǒng)。眾所周知，有的構(gòu)建系統(tǒng)異常復(fù)雜，適配過程并非易事，你得對庫的架構(gòu)，依賴關(guān)系把握非常準(zhǔn)確才行。Bazel開發(fā)團(tuán)隊也沒有提供相關(guān)工具鏈，翻譯既有存在構(gòu)建腳本，這個過程留待給用戶自行解決。

總結(jié)起來，Bazel到Make，不支持；從Make到Bazel，得出血；從Bazel到Bazel，零成本，但可能招致用戶的強(qiáng)制性。這對社區(qū)文化是一種傷害，這也是Bazel最大的硬傷。如果沒有背后有錢的老爹Google，估計Bazel早死了。

這可能與Bazel的定位和架構(gòu)有關(guān)系，大家也不能罵爹罵娘罵Google傻逼。Bazel定位在于支持多語言，而不僅僅只包括C/C++，C/C++的一些慣用法和工具鏈，在其他語言可能不成立。

此外，/usr/include, /usr/lib是系統(tǒng)目錄。如果你存在兩個工程，分別依賴于相同的、當(dāng)版本不同的庫。它們都安裝到系統(tǒng)目錄，必然存在版本沖突。幸運的是，容器時代這個問題得到了緩解。相反地，在每個Bazel項目中，將其依賴控制在自己的工作區(qū)(Workspace)內(nèi)，避免了類似的版本沖突問題。

另外，Bazel的霸道，也復(fù)合Google一貫高傲的風(fēng)格。通過Bazel的黏性，Google在多語言多語言編程領(lǐng)域，尤其在云構(gòu)建領(lǐng)域，正在積極構(gòu)建強(qiáng)大的生態(tài)系統(tǒng)和技術(shù)壁壘。

Bazel的生態(tài)系統(tǒng)不夠成熟

在C/C++領(lǐng)域，CMake，Make占據(jù)主流。Bazel作為后起之秀，能否在生態(tài)中站穩(wěn)腳跟，還得靠時間證明。此外，上文提及Bazel與社區(qū)文化存在沖突和矛盾，Bazel的生態(tài)建設(shè)還是不夠樂觀。

目前，整個Bazel的生態(tài)，基本由TensorFlow社區(qū)挑大梁。但是，TensorFlow的最佳實踐，也很難在社區(qū)中得到有效的傳播和復(fù)制。而且，TensorFlow在實踐Bazel也遇到了一些挑戰(zhàn)，包括復(fù)雜度(構(gòu)建腳本代碼行，及其依賴的復(fù)雜度)。

一方面，TensorFlow的系統(tǒng)架構(gòu)和實現(xiàn)存在固有的復(fù)雜度；因為TensorFlow是多語言、異構(gòu)的系統(tǒng)實現(xiàn)，常見的工程的構(gòu)建過程不見得擁有TensorFlow那么復(fù)雜，而且大部分公司的工程也不見得擁有Google的復(fù)雜度。在Google玩得轉(zhuǎn)的技術(shù)實踐，在其他公司并不一定有效。

另一方面，搶占既有存在的生態(tài)系統(tǒng)，本身門檻極高。猶如在Java領(lǐng)域，個人認(rèn)為Gradle比Maven優(yōu)秀，但Gradle的生態(tài)依然沒有Maven健全和完善。從社區(qū)活躍度看，目前只有Google相關(guān)的項目在推進(jìn)Bazel，其他項目幾乎沒什么動靜，由此可見一斑。

Monorepo并非是萬能的

Bazel的架構(gòu)思維是Monorepo哲學(xué)的技術(shù)延伸。但是，Monorepo是否有效，要取決于公司的文化，團(tuán)隊協(xié)助方式，項目特點等眾多因素，在日常的項目中，并非一定是靈丹妙藥。采用Monorepo組織項目，Git庫變得越來越大，甚至對IDE也提出了挑戰(zhàn)；更有甚者，Monorepo往往導(dǎo)致模塊之間的依賴隱式化，不能得到及時的顯性暴露，增加了系統(tǒng)架構(gòu)的耦合度。