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 建议将 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，工作站将使用 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 专注于解决分布式软件构建和版本管理的通用问题，并具有明确的责任范围。

利益相关方

__教员： 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 将包含一个代码库规则，用于使用 IDK 归档的内容实例化 Bazel 外部代码库，以及为 IDK 的内容（包括工具、特定于语言的库和 FIDL 定义）生成 BUILD 目标。归档应通过 ffx 或直接从 CIPD 下载。该规则可能会先下载 ffx，以便获取 IDK。

构建

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

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

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

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

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

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

一个 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 Surface。

测试

最初，测试将在 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，因此依赖于它的规则在 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 那样庞大的多语言规则生态系统。
      • 大多数替代方案不支持分布式构建的内容寻址存储。

在先技术和参考文档