RFC-0139：Bazel SDK

RFC-0139：Bazel SDK
状态已接受
区域
  • 常规
说明

设计和分发官方 Bazel SDK 的计划和要求。
Gerrit 更改
作者
审核人
提交日期（年-月-日）2021-11-16
审核日期（年-月-日）2021-11-10

修改此 RFC

修改 RFC 元数据

摘要

为了支持工作站树外构建，workstation.git 代码库将包含一个 Bazel SDK，该 SDK 最初将支持从预构建的制品构建和测试产品。此外，我们还计划支持树外驱动程序开发。为了支持这两种使用情形，此 RFC 建议将工作站 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，工作站将使用 Bazel 进行树外构建。此提案旨在制定路线图，以便在工作站之外的树外开发中普遍使用这些规则。当前 GN C++ SDK 不支持多种重要工作流程，最值得注意的是产品和驱动程序开发。这些用例应与构建 Fuchsia 平台分开支持。

支持 Bazel 等与语言无关的通用构建系统有很多好处：

一般来说，基于 Fuchsia 构建的产品（包括工作站）预计会依赖于来自不同来源的各种依赖项。这些资源包括库、可执行文件、组件、软件包、配置文件等。 这些制品可能以不同语言和架构的源代码或二进制文件的形式存在，并且可能来自第一方、第三方、公共和私有来源的组合。

IDK 包含 Fuchsia 的完整 API 接口和一套开发工具。虽然这些工具的范围和用途各不相同，但根据定义，IDK 不包含通用 build 工具，并且不建议直接使用 - 有些工具最方便的用法是从脚本中使用，而不是在终端中手动调用。

“IDK 的内容代表了 Fuchsia 平台开发者向潜在开发者提供的最基本的合约。Fuchsia IDK 不适合立即使用。它不包含对工具链或构建系统的任何引用，实际上也不需要这些工具链或构建系统的任何特定实例。”

现有的 GN C++ SDK 已被使用 GN 的 C++ 项目（例如 Flutter 和 Chromium）高效使用，但没有支持除 C++ 之外的官方 Fuchsia 语言的规范 Fuchsia SDK。GN 无法轻松扩展以支持所有 Fuchsia 官方语言，并且除非规则设计为可以相互组合，否则无法轻松组合。

Bazel 非常适合用于构建 Fuchsia 产品和 Fuchsia 软件。 Bazel 由 Google 和活跃的第三方开发者社区提供支持。 它通过以 Starlark 语言编写的 build 规则支持各种运行时目标平台和语言工具链。这些 build 规则可以发布，在各个项目中共享，并由独立开发者和大型公司在生产环境中使用。Starlark 完全可测试，并提供测试实用程序和测试指南。Bazel 旨在通过新语言、新 build 操作和集成外部依赖项的新方式进行扩展。作为一个项目，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 的每个版本还将固定到 IDK 和任何必需的工具链（例如 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 将包含一个用于实例化 Bazel 外部代码库的代码库规则，该代码库规则包含 IDK 归档的内容以及为 IDK 内容（包括工具、特定语言的库和 FIDL 定义）生成的 BUILD 目标。应通过 ffx 或直接从 CIPD 下载归档文件。该规则可能会先下载 ffx，以便获取 IDK。

建筑

以下是 Bazel SDK 必须提供的主要项：

用于构建库和可执行文件的 C++、Dart 和 Flutter 工具链。最初构建工作站时不需要 Rust，但可以稍后添加。Bazel 工具链定义应托管在与 Bazel SDK 相同的代码库中，但未来可能会移至外部。

用于从本地和远程 Fuchsia 软件包的组合中组装 Fuchsia 产品的提供程序和规则。

将特定产品映像部署到 Fuchsia 设备或模拟器的操作。

用于编译和封装可包含在产品定义中的驱动程序的规则。

封装了 IDK 中的工具的 Bazel 工具链。IDK 由 Bazel（可能通过 ffx，而 ffx 也可能由 Bazel 提取）提取，以根据 BUILD/WORKSPACE 规则中指定的版本构建产品。用于使 IDK 二进制工具可供 Bazel 规则使用。

一个针对包含软件包清单和关联文件的 Fuchsia 软件包的提供程序和规则，类似于树内 fuchsia_package 规则。

用于创建 Fuchsia 组件的提供程序和规则，具有组件清单和关联文件，类似于树内 fuchsia_component 规则。

测试

本部分指的是与测试相关的 Bazel 规则，而不是测试 Bazel SDK 本身。主要要求是支持 OOT 系统测试。

依赖项和外部代码库

这些规则将作为分析阶段的代码库规则提供。

  • 下载由外部系统构建并托管在 TUF 上的 build 工件。请参阅工作站 OOT RFC 的第 3 阶段。
  • 针对 Fuchsia 树的本地签出进行构建的代码库规则。
  • 用于针对从 CIPD 下载的特定版本的 Fuchsia IDK 进行构建的代码库规则。

实现

  • 正在 workstation.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 一部分构建的测试和示例。

在构建流程的 analysis 阶段，Bazel 可以下载制品（依赖项、工具链等）。为了在 Fuchsia CI 中支持此功能，Bazel 提供了多种机制来提前下载任何必要的制品：Bazel 离线 build。

当规则从 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 并非旨在让 build 规则跨多个项目运行。
        • 构建规则通常编写为支持在特定项目（通常是 Chromium）中构建。
        • GN 规则通常会定义/引用 build_with_chromium 变量，以选择性地支持作为 Chromium 的一部分进行构建，或使用其规则是为在 Chromium 项目中使用而编写的依赖项。
      • 上述原因均未达到 Fuchsia 预期的 API 稳定性水平。
  • 使用其他构建系统，例如 CMake、Buck、Meson 等。
    • 优点
      • 其他系统可能更受用户欢迎，因此用户更熟悉。
      • Bazel 是一个相当大的依赖项，并且会运行 Java 守护程序。有些替代方案则精简得多。
    • 缺点
      • Google 不直接支持任何一款
      • 大多数构建系统没有像 Bazel 那样庞大的多语言规则生态系统。
      • 大多数都不支持分布式 build 的内容寻址存储。

在先技术和参考资料