RFC-0139：Bazel SDK

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

針對設計及發行官方 Bazel SDK 制定及製定計畫和需求。
變更
作者
審查人員
提交日期 (年/月)2021-11-16
審查日期 (年/月)2021-11-10

編輯此 RFC

編輯 RFC 中繼資料

摘要

為了支援 Workstation Out of Tree，worker.git 存放區會包含 Bazel SDK，該 SDK 最初將支援使用預先建構的成果建構和測試產品。我們還打算支援利用樹種以外的驅動程式庫開發。為了同時支援這兩種用途，這個 RFC 建議將工作站 Bazel SDK 實際工作環境用於一般發行。原型規則目前是在 worker.git 中進行開發。一般發行作業的詳細設計將在日後的 RFC 中納入。

「SDK」不是取代或變更 Fuchsia 目前支援的 API。

Fuchsia 專案提供 IDK 和 GN C++ SDK。IDK 文件詳細資料也在 CIPD 上以「核心 SDK」一起發布，旨在做為建構「前端 SDK」的基礎。fuchsia.git 中已有一個現有產生的 Bazel SDK 前端，但該前端主要用於 IDK 的測試，且不支援一般用途。為避免混淆，應將其重新命名為「Selftest SDK」。本文件的其餘部分只會將建議樹狀結構外 Bazel SDK 稱為「SDK」或「Bazel SDK」，而 IDK (也就是「核心 SDK」) 將專門稱為「IDK」。

提振精神

根據 RFC-0095，系統會使用 Bazel 在樹狀結構外建構工作站。本提案的用意是讓這些規則正式發布，適用於工作站以外的樹狀結構外開發。目前的 GN C++ SDK 目前不支援部分重要工作流程，其中最值得注意的是產品和驅動程式庫開發作業。這些用途與建構 Fuchsia 平台應分開支援。

對 Bazel 等通用語言通用的建構系統來說，有許多原因都非常實用：

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

IDK 包含 Fuchsia 的完整 API 介面和一套開發人員工具。雖然 IDK 的範圍和用途各不相同，但不要直接使用一般建構工具，因此我們不建議直接使用，有些工具比較方便從指令碼使用，而不是在終端機中手動叫用。

「IDK 的內容代表 Fuchsia 平台開發人員向潛在開發人員提供的最基本合約，Fuchsia IDK 不適合立即使用。不含任何工具鍊或建構系統的參照，且實際上並不需要任何特定的執行個體。"

現有的 GN C++ SDK 可有效運用已採用 GN 的 C++ 專案 (例如 Flutter 和 Chromium)，但沒有標準 Fuchsia SDK 支援 C++ 官方的 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 版本。 安裝及叫用 Bazel，以便搭配 Bazel SDK 使用，建議使用 Bazelisk 和 .bazelversion 檔案。

每個 Bazel SDK 版本也都會固定為 IdP 的發布版本，以及任何必要的工具鍊 (例如 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 將詳細說明發布時的具體設計細節。

印尼盾

Bazel SDK 包含用來利用 IDK 封存內容執行個體化 Bazel 外部存放區的存放區規則，以及針對 IDK 的內容產生的 BUILD 目標，包括工具、語言專屬程式庫和 FIDL 定義。封存檔應透過 ffx 或直接從 CIPD 下載。規則可能需要先下載 ffx 以取得 IDK。

建築

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

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

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

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

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

可納入 IDK 工具的 Bazel 工具鍊。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 介面。

測試

一開始，測試會在 workstation.git 的持續測試及發布程序中，持續在 Fuchsia 基礎架構上執行測試。測試應可在 Mac 或 Linux 環境中執行。目前並未規劃 Windows 支援，而且必須等到 IDK 發布 Windows 版本後才會提供支援。為確保規則能與可能的最終相容，規則會避免使用 run_shell，以及依賴內建工具鍊的動作。Go 的工具鍊是不錯的選擇，因為 Linux、macOS 和 Windows 都支援該工具鍊，而且從這三個平台都具備良好的跨平台編譯功能。請參閱 rules_go。

Bazel SDK 應包含 Starlark 單元測試。Bazel SDK 公用 API 中的每個規則都會包含測試和範例，這些規則將做為持續整合的一部分進行建構。

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

當規則從 worker.git 移至 fuchsia-bazel-rules.git 時，CI 方案就會遵循工作站.git 方案的設計。

說明文件

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

缺點、替代方案和未知

缺點

  • Windows 上的驅動程式開發。Fuchsia IDK 不支援 Windows，因此依附於 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 Daemon。有些替代方法比較精簡。
    • 缺點
      • Google 直接不提供任何支援
      • 大多不像 Bazel 一樣大型的多語言規則生態系統。
      • 大多數版本都不支援發布分散式版本的內容定址儲存空間。

先前的圖片和參考資料