RFC-0139：Bazel SDK

RFC-0139：Bazel SDK
状态已接受
领域
  • 一般措施
说明

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

修改此 RFC

修改 RFC 元数据

总结

为了支持通过树之外的工作站 (Workstation Out of Tree)，station.git 代码库将包含一个 Bazel SDK，该 SDK 最初支持通过预构建的工件构建和测试产品。我们还计划支持树外进行驱动程序开发。为了支持这两种用例，此 RFC 提议将 Workstation Bazel SDK 生产环境化，以进行常规分发。原型规则目前是在 workspace.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 的规定，工作站将使用 Bazel 在树外构建。 此方案是一个路线图，旨在将这些规则广泛用于工作站以外的树外开发。当前的 GN C++ SDK 目前不支持一些重要的工作流程，最值得注意的是产品和驱动程序开发。这些用例应与构建 Fuchsia 平台分开支持。

支持与语言无关的通用构建系统（如 Bazel）非常有用，原因有很多：

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

IDK 包含 Fuchsia 的完整 API Surface 和一套开发工具。虽然这些工具的范围和用途各不相同，但根据定义，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 专注于解决分布式软件 build 和版本管理的一般性问题，并且具有明确的职责范围。

利益相关方

教员：hjfreyer@google.com

审核者：hjfreyer、mangini、chaselatta、amathes、sethladd、maruel、shayba、crjohns、ejia、chandarren、lijiaming、dworsham

咨询团队：驾驶团队、SDK 团队、基础架构团队、工作站团队。

社交：已发送至 eng-council-think@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 将详细说明用于分发的具体设计详情。

印度尼西亚卢比

Bazel SDK 将包含一个仓库规则，用于实例化包含 IDK 归档内容的 Bazel 外部仓库，以及为 IDK 的内容（包括工具、特定语言的库和 FIDL 定义）生成的 build 目标。归档文件应通过 ffx 下载，或直接从 CIPD 下载。该规则可能会先下载 ffx 以获得该 IDK。

建筑

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

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

用于通过本地和远程 Fuchsia 软件包组装 Fuchsia 产品的提供商和规则。

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

编译和打包产品定义中包含的驱动程序的规则。

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

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

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

测试

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

依赖项和外部代码库

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

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

实现

  • 原型规则正在工作站.git 中进行开发
  • 这些规则将移至新的 Git 代码库 (fuchsia-bazel-rules.git)。
  • 后续还会发布一份 RFC，详细说明 Bazel 规则的分发和公共 API Surface。

测试

最初，作为 Workstation.git 持续测试和发布流程的一部分，测试将在 Fuchsia 基础架构上持续运行。测试应该能够在 Mac 或 Linux 环境中运行。目前没有计划支持 Windows，并且在 IDK 有 Windows 发行版之前不会考虑支持。为了确保规则与这种可能的结果兼容，规则将避免使用 run_shell 以及依赖于内置工具链的操作。Go 的工具链是一个很好的候选平台，因为它在 Linux、macOS 和 Windows 上广受支持，并在所有三个平台上具有良好的交叉编译功能。请参阅 rules_go。

Bazel SDK 应包含 Starlark 单元测试。Bazel SDK 公共 API 中的每条规则都包含将在 CI 中构建的测试和示例。

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

当规则从 station.git 移至 fuchsia-bazel-rules.git 时，CI 方案将遵循与工作站.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 那样拥有庞大的多语言规则生态系统。
      • 其中大多数都不支持分布式 build 的内容地址存储。

早期技术和参考资料