RFC-0139：Bazel SDK

RFC-0139：Bazel SDK
狀態已接受
區域
  • 一般
說明

規劃及設計官方 Bazel SDK 的相關規定。
Gerrit 變更
作者
審查人員
提交日期 (年-月-日)2021-11-16
審查日期 (年-月-日)2021-11-10

編輯這份 RFC

編輯 RFC 中繼資料

摘要

為支援樹狀結構外的工作站，workstation.git 存放區將包含 Bazel SDK，可初步支援從預先建構的構件建構及測試產品。此外，我們也計畫支援樹狀結構外的驅動程式庫開發。為支援這兩種用途，本 RFC 建議將 Workstation Bazel SDK 投入生產，以供一般發布。原型規則目前是在 workstation.git 中開發。一般發布的詳細設計將納入日後的 RFC。

「SDK」並非指 Fuchsia 目前支援的 API 替代或變更項目。

Fuchsia 專案提供 IDK 和 GN C++ SDK。IDK 文件詳細資料：IDK 也以「核心 SDK」名稱在 CIPD 上發布，目的是做為建構「前端 SDK」的基礎。fuchsia.git 中有現成產生的 Bazel SDK 前端，但僅適用於 IDK 測試，不支援一般用途。為避免混淆，應將其重新命名為「Selftest SDK」。本文其餘部分將專指建議的樹狀結構外 Bazel SDK，並稱其為「SDK」或「Bazel SDK」，而 IDK 或「核心 SDK」則專指「IDK」。

提振精神

根據 RFC-0095，Workstation 會使用 Bazel 建構樹狀結構外的項目。這項提案是為了制定路線圖，讓這些規則普遍適用於 Workstation 以外的樹狀結構外開發作業。目前的 GN C++ SDK 尚不支援多項重要工作流程，最明顯的例子包括產品和驅動程式庫開發。這些用途應與 Fuchsia 平台建構作業分開支援。

支援 Bazel 等與語言無關的通用建構系統，有許多實用之處：

一般來說，建構在 Fuchsia 上的產品 (包括工作站) 預期會依賴不同來源的各種依附元件。包括程式庫、可執行檔、元件、套件、設定檔等。這些構件可能以不同語言和架構的原始碼或二進位檔形式存在，且可能來自第一方、第三方、公開和私人來源的組合。

IDK 包含 Fuchsia 的完整 API 介面和一套開發工具。雖然這些工具的範圍和用途各不相同，但根據定義，IDK 不包含一般建構工具，且不建議直接使用。有些工具最適合從指令碼使用，而不是在終端機手動叫用。

「IDK 的內容代表 Fuchsia 平台開發人員提供給潛在開發人員的最基本合約。Fuchsia IDK 不適合立即使用。當中沒有任何對工具鍊或建構系統的參照，事實上也不需要這些的任何特定執行個體。」

現有的 GN C++ SDK 已由使用 GN 的 C++ 專案 (例如 Flutter 和 Chromium) 採用，但沒有支援 C++ 以外 Fuchsia 官方語言的標準 Fuchsia SDK。GN 無法輕易擴充，以支援所有 Fuchsia 官方語言，且除非規則設計為可相互組合，否則無法輕易組成。

Bazel 非常適合建構 Fuchsia 產品和 Fuchsia 軟體。Bazel 由 Google 和活躍的第三方開發人員社群提供支援。 透過以 Starlark 語言編寫的建構規則，支援各種執行階段目標和語言工具鍊。這些建構規則可以發布、在專案間共用，並由獨立開發人員和大型企業用於生產環境。Starlark 完全可測試，並提供測試公用程式和測試指南。Bazel 的設計宗旨是可擴充，支援新語言、新建構動作，以及整合外部依附元件的新方式。做為專案，Bazel 專注於解決分散式軟體建構和版本管理的一般問題，並有明確的責任範圍。

利害關係人

導師：hjfreyer@google.com

審查者：hjfreyer、mangini、chaselatta、amathes、sethladd、maruel、shayba、crjohns、ejia、chandarren、lijiaming、dworsham

諮詢對象：驅動程式團隊、SDK 團隊、基礎架構團隊、工作站團隊。

社交化：已傳送至 eng-council-discuss@fuchsia.dev

設計

詳細的技術設計將是這項 RFC 的後續步驟。這項 RFC 列出 RFC 的廣泛需求，但未指定實作方式。

版本管理

規則應一律固定在最新 LTS 版本的 Bazel。 建議使用 Bazelisk 和 .bazelversion 檔案安裝及叫用 Bazel，以便搭配 Bazel SDK 使用。

每個 Bazel SDK 版本也會固定為 IDK 和任何必要工具鍊 (例如 Clang) 的發布版本。Bazel SDK 會根據主機 OS 擷取固定的 IDK 和工具鍊封存檔。IDK 和工具鍊封存檔也應可覆寫為本機檔案，以利開發。

程式碼位置

Workstation.git 包含原型 Bazel 規則，可支援組裝產品、編譯 C++ 元件，以及編譯 Flutter 元件。這些規則會固定在特定版本的 Fuchsia IDK，並使用分散式產品整合。

開發作業將移至名為 fuchsia-bazel-rules.git 的新存放區。這是因為 Fuchsia IDK 版本不是從 fuchsia.git 的單一結帳程序建立，而且為了使用最新版 IDK，Bazel 規則必須存在於 fuchsia.git 的下游。

發布

後續的 RFC 將會釐清發布的具體設計細節。

IDK

Bazel SDK 會包含存放區規則，用於以 IDK 封存檔案的內容例項化 Bazel 外部存放區，以及為 IDK 的內容 (包括工具、語言專用程式庫和 FIDL 定義) 產生 BUILD 目標。封存檔應由 ffx 下載，或直接從 CIPD 下載。規則可能會先下載 ffx，以取得 IDK。

建築

Bazel SDK 必須提供下列主要項目：

C++、Dart 和 Flutter 工具鍊，用於建構程式庫和可執行檔。一開始建構 Workstation 時不需要 Rust，但之後可以新增。Bazel 工具鍊定義應與 Bazel SDK 位於同一個存放區，但未來可能會移至外部。

供應商和規則，可從本機和遠端 Fuchsia 套件的組合組裝 Fuchsia 產品。

將特定產品映像檔部署至 Fuchsia 裝置或模擬器的動作。

編譯和封裝驅動程式的規則，這些驅動程式可納入產品定義。

Bazel 工具鍊，可包裝 IDK 中的工具。Bazel 會擷取 IDK (可能透過 ffx，這也可能由 Bazel 擷取)，根據 BUILD/WORKSPACE 規則中指定的版本建構產品。這是為了讓 Bazel 規則使用 IDK 二進位工具。

Fuchsia 套件的供應商和規則，包含套件資訊清單和相關聯的檔案，類似於樹狀結構內的 fuchsia_package 規則。

建立 Fuchsia 元件的供應商和規則，其中包含元件資訊清單和相關聯的檔案，類似於樹狀結構內的 fuchsia_component 規則。

測試

本節是指與測試相關的 Bazel 規則，而非測試 Bazel SDK 本身。主要需求是支援 OOT 系統測試。

依附元件和外部存放區

這些規則會以分析階段的存放區規則形式提供。

  • 下載由外部系統建構並託管於 TUF 的建構成果。請參閱工作站 OOT RFC 的第 3 階段。
  • 針對 Fuchsia 樹狀結構的本機結帳版本建構的存放區規則。
  • 存放區規則，用於建構從 CIPD 下載的特定 Fuchsia IDK 版本。

實作

  • 工作站的 git 中正在開發原型規則
  • 這些規則會移至新的 Git 存放區 (fuchsia-bazel-rules.git)。
  • 後續將發布 RFC，詳細說明 Bazel 規則的發布和公開 API 介面。

測試

一開始，測試會在 Fuchsia 基礎架構上持續執行，這是 workstation.git 持續測試和發布程序的一部分。測試應能在 Mac 或 Linux 環境中執行。目前我們不打算支援 Windows，而且在 IDK 的 Windows 發行版本推出前，也不會考慮支援 Windows。為確保規則與這類事件相容，規則會避免使用 run_shell，以及依賴內建工具鍊的動作。Go 的工具鍊是不錯的選擇，因為它在 Linux、macOS 和 Windows 上都獲得良好支援，且這三個平台都具備良好的跨平台編譯功能。請參閱 rules_go。

Bazel SDK 應包含 Starlark 單元測試。Bazel SDK 公開 API 中的每項規則都會包含測試和範例，這些內容會建構為 CI 的一部分。

Bazel 可以在建構程序的 analysis 階段下載構件 (依附元件、工具鍊等)。為在 Fuchsia CI 中支援這項功能，Bazel 提供多種機制，可預先下載任何必要構件：Bazel 離線建構。

規則從 workstation.git 移至 fuchsia-bazel-rules.git 時，CI 配方會採用與 workstation.git 配方相同的設計。

說明文件

Stardoc 應與持續測試一併執行，在存放區中產生格式化文件。這份文件應整合至 fuchsia.dev，其中其他文件會說明使用者安裝 Bazel 的建議方式 (使用 bazelisk)。

缺點、替代方案和未知事項

缺點

  • 在 Windows 上開發驅動程式。Fuchsia IDK 不支援 Windows，因此依附於該 IDK 的規則無法在 Windows 系統上運作。

替代方案

  • 擴充 GN C++ SDK，支援上述工作流程。
    • 優點
      • 以現有工作為基礎，逐步完成。
      • 部分規則可直接從 fuchsia.git 遷移，且變更幅度極小。
      • 大多數 Fuchsia 開發人員都有 GN 經驗。
    • 缺點
      • GN 的發布版本沒有簡單的版本配置，專案會與特定 GN 版本綁定，且無法保證向前或向後相容。這點很重要，因為這些規則預計會與其他方發布的規則一併使用。
      • GN 的設計目的並非讓建構規則跨多個專案運作。
        • 建構規則通常是為了支援在特定專案 (通常是 Chromium) 中建構而編寫。
        • GN 規則通常會定義/參照 build_with_chromium 變數，以選擇性支援建構為 Chromium 的一部分，或使用其規則是為 Chromium 專案編寫的依附元件。
      • 上述原因未達到 Fuchsia 預期的 API 穩定性。
  • 使用其他建構系統，例如 CMake、Buck、Meson 等。
    • 優點
      • 使用者可能更喜歡其他系統，因此也更熟悉該系統的操作方式。
      • Bazel 是相當大的依附元件，而且會執行 Java 常駐程式。有些替代方案的負擔較輕。
    • 缺點
      • Google 不直接支援任何裝置
      • 大多數建構系統的多語言規則生態系統，都不像 Bazel 那麼龐大。
      • 大多數都不支援分散式建構的內容定址儲存空間。

既有技術和參考資料