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（在 CIPD 上也以“核心 SDK”的名称分发）旨在作为构建“前端 SDK”的基础。fuchsia.git 中存在已生成的 Bazel SDK 前端，但它仅用于测试 IDK，不支持一般用途。为避免混淆，应将其重命名为“自测 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 SDK 支持官方 Fuchsia 语言。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-discuss@fuchsia.dev

设计

我们将在本 RFC 后续跟进详细的技术设计。此 RFC 概述了 RFC 的一般要求，但未指定实现这些要求的方法。

版本控制

这些规则应始终固定到最新的 LTS 版 Bazel。建议使用 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 内容生成的 BUILD 目标，包括工具、特定于语言的库和 FIDL 定义。应通过 ffx 或直接从 CIPD 下载归档文件。该规则可能会先下载 ffx，以获取 IDK。

建筑

Bazel SDK 必须提供以下主要内容：

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

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

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

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

用于封装 IDK 中工具的 Bazel 工具链。Bazel 会提取 IDK（可能通过 Bazel 也可能通过 ffx 提取），以便根据 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 接口的具体信息。

测试

最初，测试将在 Fuchsia 基础架构上持续运行，作为 workstation.git 的持续测试和发布流程的一部分。测试应能够在 Mac 或 Linux 环境中运行。目前不打算支持 Windows，除非有适用于 Windows 的 IDK 分发版本。为了使规则与这种可能发生的情况保持兼容，规则将避免使用 run_shell 和依赖于内置工具链的操作。Go 工具链是一个不错的选择，因为它在 Linux、macOS 和 Windows 上都得到了良好的支持，并且在所有三个平台上都具有良好的跨编译功能。请参阅 rules_go。

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

Bazel 可以在其构建流程的 analysis 阶段下载工件（依赖项、工具链等）。为了在 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 不适用于跨多个项目运行的构建规则。
        • 构建规则通常编写为支持在特定项目（通常是 Chromium）中构建。
        • GN 规则通常会定义/引用 build_with_chromium 变量，以选择性支持作为 Chromium 的一部分进行构建，或使用规则是为在 Chromium 项目中使用而编写的依赖项。
      • 上述原因不符合 Fuchsia 预期的 API 稳定性级别。
  • 使用其他构建系统，例如 CMake、Buck、Meson 等。
    • 优点
      • 另一个系统可能更受用户欢迎，因此更易于使用。
      • Bazel 是一个非常大的依赖项，并运行 Java 守护程序。有些替代方案要精简得多。
    • 缺点
      • 均不受 Google 直接支持
      • 大多数工具的多语言规则生态系统不如 Bazel 那样庞大。
      • 大多数不支持分布式 build 的内容寻址存储。

在先技术和参考文档