是时候采用新的嵌入式Linux构建系统了吗？

# 是时候该有新的嵌入式 Linux 构建系统了吗？ — [yoe] 来源：https://yoebuild.org/blog/time-for-a-new-build-system/ 在过去 20 年里，我一直在使用嵌入式 Linux 构建产品。我第一次尝试 OpenEmbedded（Yocto 的前身）时，感觉就像是一份礼物——只需运行一条命令，就能在我的 x86 工作站上构建一个可启动的 ARM 镜像。但情况正在发生变化。我们可用的组件（包括硬件和软件）越来越多。我们有 AI 工具。我们有性能强大、内存巨大的处理器。小团队（创业公司和构建中小批量联网产品的工业企业）想做更大的事情，却苦于将这一切拼接起来的复杂性，错过了发货期限，并在设备投入现场后难以维护。本文探讨了哪些方面发生了变化，以及我们如何能够更高效地构建和维护嵌入式 Linux 系统。 ## 嵌入式系统的黄金时代 (https://yoebuild.org/blog/time-for-a-new-build-system/#the-embedded-systems-golden-age) 我们正处在一个嵌入式系统工程卓越的时代。我们拥有： - 大量的 Linux 系统级模块 (SOM)，是工业产品的完美硬件构建模块。 - Zephyr，一个在 MCU 平台上构建软件的优秀操作系统。 - 成熟的工具（编译器、构建系统等）。 - 大量可用于这些系统的开源软件。 - 快速、价格合理的原型制作（PCB 组装、机械 3D 打印等）。 - 更多供应商将其 Linux 内核支持上游化。 - Yocto 用于构建镜像和系统自定义部分的可靠工具。 而且，所有这些对任何规模的公司都可用。这有点像继承了一座豪宅：开源给了我们一栋巨大的房子，里面满是房间和功能，我们自己永远也建不出来，为了保持竞争力，我们必须住进去。问题在于，没有人给我们维护这座房子的工具。除了我们将所有东西整合在一起的能力，没有其他阻碍。 ## 当前嵌入式 Linux 系统的构建方式 (https://yoebuild.org/blog/time-for-a-new-build-system/#how-embedded-linux-systems-are-currently-built) 嵌入式 Linux 构建系统解决了将所有部分组合在一起的问题，现有的系统一直为我们服务得很好。Buildroot（2001年）和 OpenEmbedded/Yocto（2003年）现在是标准，受到大多数 SOC/SOM 供应商的支持，一些团队成功地在 Debian、Ubuntu 甚至 Arch（如 Valve 在 Steam Deck 上所做的那样）上发货。 主流嵌入式 Linux 开发的形态在约 20 年间一直非常稳定：在强大的 x86 工作站上进行交叉编译，组装 BSP（板级支持包），冻结 SDK（软件开发工具包），发布镜像，然后保持这个状态多年。这是一个为静态、单一用途、极少更新的产品构建的模型，直到最近，对于这类产品，它都运行良好。 ## 但情况正在发生变化…… (https://yoebuild.org/blog/time-for-a-new-build-system/#but-things-are-changing) 产品的变化已经超过了构建它们的工具。边缘设备开始表现得像云系统。它们运行容器，拉取 OTA（空中下载）更新，流式传输遥测数据，并在其整个生命周期内被远程管理。设备不再是一个你刷写一次就忘记的静态产物；它是一个在发货后继续向前发展的系统。这颠覆了旧的发布节奏：不是冻结 SDK 并维持多年，而是团队持续跟踪上游并顺理成章地推送更新。交叉编译模型所依赖的长时间 LTS（长期支持）冻结已不再适合新的产品类别。 与此同时，软件本身也已经超出了交叉编译模型的范围。现代语言各自拥有自己的包生态系统：Python（通过 NumPy 和 PyTorch 包装 C/C++/CUDA）、JavaScript（链接到 C 库）、Go、Rust 和 vcpkg（用于 C/C++）。其中大部分是为桌面/服务器编写的，而不是为交叉编译。这直接将交叉编译的负担放在了嵌入式开发者身上，而为成千上万个包维护配方一直是对 Yocto 社区的持续消耗。Yocto 通过阻止构建期间的网络访问加剧了这一点，因此如果没有复杂的 `do_fetch` 集成，语言包工具就无法工作。当你必须控制每个源代码时，这很有用，但对许多项目来说是不必要的摩擦。 这些解决方案都是在用一种问题换取另一种问题。在 Yocto 中从源码构建所有东西意味着构建时间长、内存使用高以及需要强大的工作站。像 Debian 这样的现成二进制发行版可以更快地开始开发，但缺乏集成自定义部分的工具。而供应商 BSP 冻结在四年前的 Yocto 版本上，使得集成现代软件变得非常困难。 我们可以继续列举，但原因在于结构性问题。才华横溢的团队努力工作仍然会遇到这个问题，因为问题本身就很困难，而且软件变得越来越难构建。 总结一下，有三件事发生了变化： 1. **产品从未停止发展。** 边缘设备现在表现得像云系统：持续的 OTA 更新，而不是多年的冻结。 2. **软件超出了交叉编译的范围。** 每一种现代语言都带来了自己的包生态系统，而这些生态系统并不总能干净地交叉编译。 3. **旧的权衡变得更加明显。** 从源码构建缓慢且沉重；现成发行版缺乏自定义工具；BSP 将你冻结在某个时间点。 旧的模型很好。真正的问题是它是否仍然适合你正在构建的产品和你拥有的团队。 ## 小团队面临的问题不同，而非更小 (https://yoebuild.org/blog/time-for-a-new-build-system/#small-teams-have-different-problems-not-smaller-ones) 我一直与很多构建产品的人交流，并且不断听到一致的信息。首先，根基已经改变：产品和我们必须将它们组合在一起的方式都变了。其次，对大团队有效的东西对小团队不一定有效。 小团队和创业公司需要构建和发货。他们往往没有资源来维持多年的开发周期。他们没有专门的构建或平台工程师来创建复杂的构建基础设施和调试困难的构建问题。简单易用的构建/部署通常比二进制可重现构建或从头构建所有东西更重要。轻松部署最新的开源版本通常是利用新技术的必要条件。 这些团队常常受到三件事的阻碍：供应商 BSP 将他们锁定在旧版本的 Yocto 上，令人沮丧的调试周期中关键组件无法构建，以及将所需组件回溯移植到冻结的系统中需要大量的精力。大型组织可以雇佣专门的专家并向这些问题投入资源。小组织没有这种奢侈。 明确一点，小 ≠ 爱好者。这些通常是创业公司或中等规模（几百到几千台）的工业产品，介于一次性创客项目和消费级大规模生产之间。 ## 新的机遇 (https://yoebuild.org/blog/time-for-a-new-build-system/#the-new-opportunity) Buildroot 和 OpenEmbedded 诞生于这样一个时代：基于 ARM 的计算机速度缓慢，在强大的 x86 工作站上交叉编译软件是唯一实用的选择。当我们构建的是一组有限的基于 C/C++ 的应用程序时，这些系统工作得很好。然而，最近有几件事发生了变化： 1. 应用程序开发正在转向现代语言（Python、JS、Go、Rust、Zig）。这些语言有自己的包生态系统、缓存等。 2. 硬件情况发生了逆转。我们现在有了可用于构建的快速 ARM 计算机（AWS Graviton、Hetzner CAX），不再局限于 x86 工作站。 3. AI 已崛起为创建软件（包括构建系统）的强大工具。 我们需要利用这些变革力量，重新思考互联产品的世界。关键转变是这样的：停止只借用现代生态系统的*技术*，开始也借用它们的*流程*。当我们采用 Rust 或 Python，使用了语言却将其强加于旧的构建流程时，这有点像在柏油路上跑火车。真正的优势来自于采纳这些生态系统构建、打包和缓存的方式，而不仅仅是它们产生的结果。 我们现在有机会重新思考嵌入式 Linux 构建系统。对我个人而言，这变得切身起来。最近我意识到——如果我要继续做这个工作 20 年，我想要一些不同的东西，一些更适合我和我的客户实际试图解决的问题的工具，而不是与工具本身作斗争。 所以我一直在实验。在过去的几个月里，我一直在公开地构建这些真实的组成部分，早期的结果令人鼓舞：过去意味着要花一天时间与交叉编译作斗争的软件，现在只需几分钟就能从想法变成在目标硬件上运行，在我的笔记本电脑和 CI 中使用相同的工具。这还很粗糙和早期，但足以让我相信这个方法是值得追求的。 ## 如果…… (https://yoebuild.org/blog/time-for-a-new-build-system/#what-if) ……我们可以： - **更快地推向市场。** 缩短从想法到工作产品的路径。- 在几秒到几分钟内（而不是几天或几周）将想法变成在目标硬件上运行。 - 不需要交叉编译。 - 利用现代语言生态系统（Python、JavaScript、Rust、Go、Zig、pkgbuild 等）。 - 缓存构建，这样没有软件会被构建两次。 - 提供主流发行版的预构建包的便利，同时拥有 Yocto 的工具优势。 - **用一个小团队做更多事情。** 整个团队（和 AI）都可以使用一个工具集，这样你就不需要专门的构建专家。- 为应用程序和系统软件提供一个构建系统：在笔记本电脑、云 CI 和构建农场中使用相同的工具。 - 易于人类和 AI 理解。 - 包括与 AI 代理配合良好的工具。 - 利用 AI 完成大部分底层工作。 - 提供能清晰指出问题的错误消息。 - **保持产品最新并在现场可支持。** 轻松跟踪现代软件版本，并在设备的整个生命周期内维护它们。- 轻松跟踪当前软件版本，而不受供应商 BSP 的拖累。 - 从系统到应用程序再到 CI，使用一致的工具进行扩展。 - 轻松地将更新部署到现场设备。 （这些问题似乎是普遍的，但它们对小团队的影响尤其严重，因为这些团队很少拥有专门的资源来解决它们。） 这就是我正在这个[下一代嵌入式 Linux 构建系统](https://yoebuild.org/)中实验的内容。以下是一些例子，展示了该工具如何使开发更容易： - [Alpine](https://yoebuild.org/blog/first-walkthrough-videos/)、[Debian](https://yoebuild.org/blog/adding-debian/) 和 [Ubuntu](https://yoebuild.org/blog/adding-ubuntu/) 都是支持的基础发行版，让我们无需重建整个系统就能快速开始。 - 集成 [Python 和 JavaScript](https://yoebuild.org/blog/pip-and-npm-on-the-target/) 的原生包生态系统，而不是与之对抗。 - [一流的 AI 支持](https://yoebuild.org/blog/ai-integration/)。 - [终端用户界面 (TUI)](https://yoebuild.org/blog/why-a-tui/) 速度快，允许我们轻松监控正在发生的事情，并根据需要深入到详细信息。 还有一些关键功能缺失，比如分布式缓存和远程构建运行器，但这些很快就会到来。 ## 旧模型仍有其用武之地 (https://yoebuild.org/blog/time-for-a-new-build-system/#the-old-models-still-have-their-place) 这并不意味着旧模型会消失或不应该存在。对于深度嵌入式的合规产品（经过认证、比特可重现、完全从源码构建、有意冻结多年），Yocto 经过实战检验，仍然是正确的工具。它完全满足了这些产品的需求，并且做得很好。 我们以前见过这种模式。Alpine Linux 并没有取代 Debian。它满足了一个不同的需求：最小的、容器友好的镜像。两种发行版至今仍在发布，服务于设计空间中的不同点。没有人将其视为竞争；它们只是为不同的工作而塑造的。 这里也是如此。动态的、互联的、频繁更新的、用现代语言构建的设备是不同的工作，它们值得一个为此工作而构建的工具。 ## 那么，是时候了吗？ (https://yoebuild.org/blog/time-for-a-new-build-system/#so-is-it-time) 对于真实存在且不断增长的团队和产品类别来说，我认为答案是肯定的。[`[yoe]` build](https://yoebuild.org/) 是一个早期的实验，探索这可能是什么样子。它处于 1.0 之前的阶段，在公开环境中开发，粗糙的边缘等等。这是一个赌注，认为这是一个值得解决的问题，也是一个邀请，让我们一起找出解决方案的形态。 这取决于你们：构建产品的团队和支持他们的供应商。提供反馈。我遗漏了什么？测试一下，让我知道它的效果如何。[注册](https://yoebuild.org/)我的新闻通讯。告诉你的供应商你需要这样的东西。喜欢/监控 [GitHub 仓库](https://github.com/yoebuild/yoe)。分享给可能感兴趣的人。贡献改进。资助开发或基础设施。许多小团队需要这个，这些小型公司构成了全球经济的重要组成部分（长尾）。创业公司是大量创新的发生地。如果涌现出一个能够利用现代 AI 工具的社区，这就会发生。过去两个月的[进展](https://github.com/yoebuild/yoe/releases)证明了这是可能的。