RFC-0139：Bazel SDK

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

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

編輯此 RFC

編輯 RFC 中繼資料

摘要

為了支援Workstation Out of Tree，workstation.git 存放區將納入 Bazel SDK，這項 SDK 最初會支援使用預先建構的構件建構及測試產品。我們也計劃支援樹狀結構外的驅動程式庫開發作業。為支援這兩種用途，本 RFC 建議將 Workstation Bazel SDK 推向一般發布環境。原型規則目前是在 workstation.git 中開發。日後的 RFC 將納入一般發布的詳細設計。

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

Fuchsia 專案提供 IDK 和 GN C++ SDK。IDK 說明文件詳細說明 IDK (在 CIPD 上也以「核心 SDK」名稱發行) 是用來建構「前端 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 SDK 支援官方 Fuchsia 語言。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 的一般要求，但未明確說明如何實作。

版本管理

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

每個 Bazel SDK 版本都會綁定至 IDDK 和任何必要工具鍊 (例如 Clang) 的版本。Bazel SDK 會根據主機作業系統擷取已固定的 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 內容產生的 BUILD 目標，包括工具、語言專屬程式庫和 FIDL 定義。您應透過 ffx 或直接從 CIPD 下載封存檔。規則可能會先下載 ffx，以便取得 IDK。

建築

以下是 Bazel SDK 必須提供的主要項目：

C++、Dart 和 Flutter 工具鍊，可用於建構程式庫和可執行檔。建構工作站時，一開始不需要使用 Rust，但之後可以新增。Bazel 工具鍊定義應與 Bazel SDK 同樣託管在同一個存放區，但日後可移至外部。

提供者和規則，可透過結合本機和遠端 Fuchsia 套件來組合 Fuchsia 產品。

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

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

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

適用於 Fuchsia 套件的提供者和規則，其中包含套件資訊清單和相關聯的檔案，類似於樹狀結構內的 fuchsia_package 規則。

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

測試

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

依附元件和外部存放區

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

  • 下載由外部系統建構並在 TUF 上代管的建構構件。請參閱工作站 OOT RFC 的第 3 階段。
  • 針對 Fuchsia 樹狀結構的本機檢出的建構作業，適用的存放區規則。
  • 針對從 CIPD 下載的特定 Fuchsia IDK 版本建構的存放區規則。

實作

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

測試

一開始，測試會在 Fuchsia 基礎架構上持續執行，作為 workstation.git 的持續測試和發布程序的一部分。測試應可在 Mac 或 Linux 環境中執行。目前尚未規劃 Windows 支援功能，且在 IDDK 的 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，因此依附於該系統的規則無法在 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 那樣龐大的多語言規則生態系統。
      • 大多數都不支援分散式版本的內容位址儲存空間。

既有技術與參考資料