最佳做法

回報問題 查看原始碼 。 。 。 。 夜間。 。 7.3 。 。 7.2 。 。 7.1 。 。 7.06.5

本頁面假設您已熟悉 Bazel,並提供相關指南和 有關建構專案的建議,以充分利用 Bazel 的功能。

整體目標如下:

  • 使用精細的依附元件來允許平行處理和漸進式。
  • 確保依附元件封裝良好。
  • 讓程式碼結構化且易於測試。
  • 建立易於理解及維護的建構設定。

這些準則並非必要條件:少數專案可以符合 全部都沒問題就像 Lint 的主頁一樣: 第一次發展一個真正的程式 進行嚴格檢查但是,應盡可能採用這些原則 應該讓專案更容易閱讀、不容易出錯,同時加快建構速度。

本頁面將採用 此 RFC

執行建構和測試

專案應一律能夠執行 bazel build //...,並 bazel test //... 已成功使用穩定的分支版本。必要的目標 但請勿在特定情況下建構 (例如需要特定建構 或不在特定平台上發布內容、需要授權協議) 盡可能明確加入標記 (例如「requires-osx」)。這個 標記可讓您以更精細的方式篩選目標 「手動」標記並方便他人檢查 BUILD 檔案 目標的限制

第三方依附元件

您可以宣告第三方依附元件:

  • 請在 WORKSPACE 檔案中將這些 API 宣告為遠端存放區。
  • 也可以在工作區目錄下,將這些檔案存放在名為 third_party/ 的目錄中。

視二進位檔而定

請盡可能從來源建構所有項目。這通常意味著 如此一來,與其依附於程式庫 some-library.so 時,您都可以建立 BUILD 檔案,並從來源建構 some-library.so,然後依附於 目標。

一律從原始碼建構,可確保建構作業不會使用會執行以下程式碼的程式庫: 並使用不相容的旗標或不同架構來建構。此外, 例如涵蓋範圍、靜態分析或動態分析 都會對原始碼造成影響

版本管理

偏好盡可能從頭建構所有程式碼。版本須為 ,請避免在目標名稱中加入版本 (例如 //guava、 並非 //guava-20.0)。這項命名方式可簡化程式庫的更新程序 (只使用一個 目標需要更新)。更能恢復鑽石的依賴性 問題:如果一個程式庫依附於 guava-19.0,而另一個程式庫依附於 guava-20.0, 這個程式庫會嘗試依靠兩個不同版本。 如果您建立了誤導性的別名,將兩個目標指向一個 guava 程式庫, BUILD 檔案會誤導使用者

使用 .bazelrc 檔案

如需專案專屬選項,請在 workspace/.bazelrc (請參閱 bazelrc 格式)。

如果您要為專案支援其他使用者選項,但「並未」 需要檢查原始碼控管位置,請包含以下這一行:

try-import %workspace%/user.bazelrc

在您的 workspace/.bazelrc 中 (或任何其他檔案名稱) 並將 user.bazelrc 新增到您的 .gitignore

套件

包含可建構檔案的每個目錄都應為一個套件。如果BUILD 檔案指的是子目錄 (例如 srcs = ["a/b/C.java"]) 中的檔案 一個符號,表示 BUILD 檔案應新增至該子目錄。長久 因此更有可能出現循環相依關係 目標的範圍會逐漸擴大 反向依附元件的元件必須更新