本頁面假設您已熟悉 Bazel,並提供指南與建議,協助您建構專案,以便充分利用 Bazel 的功能。
整體目標如下:
- 使用精細依附元件,允許平行處理和增量處理。
- 可確保依附元件妥善封裝。
- 讓程式碼結構良好且可供測試。
- 建立易於理解及維護的建構設定。
這些規範並非必要條件,很少有專案能遵循所有規範。如 lint 的 man 頁面所述,「如果有人能製作出在嚴格檢查下不會產生錯誤的實際程式,我們會頒發特別獎勵。」不過,要盡量整合這些原則,可使專案更容易閱讀、較不容易出錯,以及建構速度更快。
本頁面採用此 RFC 中所述要求層級。
執行建構和測試
專案應一律能夠在穩定分支中順利執行 bazel build //...
和 bazel test //...
。對於某些必要但在特定情況下不建構的目標 (例如需要特定建構旗標、不在特定平台上建構、需要授權協議),請盡可能明確標記目標 (例如「requires-osx
」)。此標記可讓目標以比「手動」標記更精細的層級篩選,並讓使用者查看 BUILD
檔案,藉此瞭解目標限制。
第三方依附元件
您可以宣告第三方依附元件:
- 請在
WORKSPACE
檔案中將這些 API 宣告為遠端存放區。 - 或者,您也可以將這些檔案放在工作區目錄下的
third_party/
目錄中。
取決於二進位檔
請盡可能從來源建構所有項目。一般來說,您會建立一個 BUILD
檔案,並從其來源建構 some-library.so
,再依附於該目標,而非仰賴程式庫 some-library.so
。
一律從原始碼開始建構,可確保建構作業不會使用以不相容的標記或不同架構建構的程式庫。另外,還有一些功能 (例如涵蓋率、靜態分析或動態分析) 只適用於原始來源。
版本管理
偏好盡可能從頭建構所有程式碼。當必須使用版本時,請避免在目標名稱中加入版本 (例如,//guava
,而非 //guava-20.0
)。這種命名方式可讓程式庫更容易更新 (只需要更新一個目標)。此外,這類問題更有效處理鑽石的依附元件問題:如果一個程式庫依附 guava-19.0
,而另一個程式庫依附 guava-20.0
,則最終可能會有一個程式庫嘗試依附兩個不同版本。如果您建立會誤導使用者的別名,將兩個目標指向一個 guava
程式庫,那麼 BUILD
檔案會誤導使用者。
使用 .bazelrc
檔案
如需專案專屬選項,請使用 workspace/.bazelrc
的設定檔 (請參閱 bazelrc 格式)。
如果您想為專案支援「不想」簽入來源控制的每位使用者選項,請加入以下這行:
try-import %workspace%/user.bazelrc
(或任何其他檔案名稱),並將 user.bazelrc
新增至 .gitignore
。
套件
每個包含可建構檔案的目錄都應為套件。如果 BUILD
檔案參照子目錄中的檔案 (例如 srcs = ["a/b/C.java"]
),表示應將 BUILD
檔案新增至該子目錄。這個結構的存在時間越長,就越有可能在無意間建立循環依附元件,目標的範圍也會變小,而且必須更新越來越多的反向依附元件。