為什么google bazel構建工具流行不起來
作者Jack47
之前博主寫了系列文章Google軟件構建工具Bazel原理及使用方法介紹。最近使用了一段時間后，覺得這個東西不是一種通用的構建工具，很難對接到情況復雜的大的工程項目里。今天來講講為什么博主覺得google bazel構建工具不會大規模流行起來。本文是參考Gradle--另外一個很出名的構建工具--的人對bazel的看法的這篇文章基礎上整理而成的
Google bazel想解決什么問題？
Bazel是Google內部構建系統Blaze的子集，所以Bazel想解決的最主要是Google所面臨的獨一無二[可能不完全是]的問題“：
這篇文章記錄了Google面臨的問題：
Google的代碼庫是非常巨大的（有數百萬行代碼），好處是公司內部都推行一套統一的開發風格。例如，對每種語言都有寫好的風格規范，有一個多語言的構建系統來給所有的項目構建代碼，源代碼都在一個地方存放，一個統一的持續集成來運行所有的單測。軟件工具開發者們可以訪問并分析到所有的代碼，每個人都使用相同的code reviews工具并使用同一套索引來搜索代碼庫
所有代碼都在一個源代碼倉庫里，因此Google是世界上少數幾個遇到這樣大規模問題的公司，所以構建過程中的性能問題是最關鍵的需求，其他需求都是次要的，尤其是跟Google不相關的需求。可惜的是大部分公司都不是Google，有更廣泛的需求。
bazel為什么不適合其他公司
大部分公司都不是Google的這種情況，不會有強大的構建團隊來專門做軟件構建相關的工具，也不會有Google那么好的開發文化，沒有統一的構建工具，因此大項目想對接bazel，會遇到很多困難。
Google 內部軟件構建系統已經開發了超過7年了，所以開發適合Google自己的構建工具是他們的初衷。Google構建工具跟其他工具相比，強調的是“更加結構化”，這樣能夠提高并發度，擁有更好的可重現性[reproducibility]。但這樣對源代碼的組織方式和頭文件的書寫規則，庫之間依賴關系的書寫要求就比較高：
- 要求所有相關的源代碼都以Bazel要求的組織形式來發布：
- 要求所有代碼的傳遞依賴都存儲在一個代碼倉庫里
- 所有的庫和相關的工具都是提交到這個代碼庫里。
以上這幾點是很難同時達到的，大部分公司管理依賴關系的方式都不盡相同。舉個例子，在Linux下開發，很多包是rpm形式發布的，對于這種第三方的包，就很難實現Bazel的要求，不可能要求每個rpm包都提供Bazel的依賴描述文件：BUILD文件，而且在構建過程中，怎么把rpm文件組織到工程的源代碼里面，也是一個頭疼的問題。雖然有辦法也可以做到，例如使用程序自動下載，解壓rpm文件，然后生成BUILD文件，但是這當中會遇到很多一些問題。所以google的bazel這一套構建工具，需要公司里上下游的開發團隊都用起來，才能發揮應有的效益。
另外一個原因是Bazel目前不支持Windows操作系統。