这是一篇关于 2024 年编写可引导相关软件的最佳选择的文章，主要内容如下：

• 项目背景：作者有一个新生的副业项目打算参与引导链，由于项目不应依赖过多东西，其构建依赖的传递闭包也应较小，且在构建过程中不应依赖不透明的二进制块，所以语言选择受限。
• 语言选择：Zig 目前不是候选语言，尽管其语言本身很有前景，但已移除基于 C++的引导，改为保留之前编译器版本的 WASM 构建，目前不是真正可引导的；Rust 因文中所述原因也被排除。目前看来，2024 年编写引导相关软件的最佳选择仍是 C99，且依赖尽可能少，必要依赖也应是可引导的、用 C99 编写，并提供pkg-config风格的.pc文件描述必要的编译器/链接器标志。

• 构建系统选择：

  • Autotools：作者过去一直将automake（和其他 Autotools）用作 C 项目的首选构建环境，对于简单项目设置起来并不费力，能免费获得很多东西，但 Autotools 也有其缺点，如需要使用古老的语言编写宏、许多工具维护不佳、构建速度慢、automake未真正摆脱递归 make 习惯、libtool导致对象文件混乱、开启目标标志时对象文件名丑陋、许多“现代”功能默认关闭等。
  • Meson：似乎是推荐的现代、可移植的 C 构建系统，但作者认为它在编写可引导软件方面有很多缺点，如依赖 Python 和ninja，设计围绕已知编译器列表，默认生成.tar.xz归档且不支持更改默认格式，subdir()调用不隔离，避免subdir()编写单级meson.build较尴尬，不清楚运行meson还是ninja完成某些任务等。不过作者也承认 Meson 设计有很多优点，如只有一种语言、能整体看待项目、源发行版无生成文件、使用源控制作为分发档案基础、易指定 C 标准和警告级别、支持 asan 和 ubsan、编译器是对象可针对特定编译器配置、支持交叉编译和 Windows 等。
• 可能的解决方案：muon和 Samurai 项目是 C99 重实现的meson和ninja，作者认为它们在引导方面有考虑，但muon不支持 Meson 的所有功能，如不支持default_optionskwarg、不支持muon dist、不支持交叉编译、不支持hotdoc等。
• 前进路径：如果关心编写可引导软件，有两条不错的前进路径，一是使用 Meson 作为构建语言，使用muon和 Samurai 进行常规开发，用 Meson 运行“项目管理”任务；二是回到automake，接受其额外的缺点以保证依赖集小，可使用非递归Makefile.am和SUBDIRS。同时，考虑针对 VCS 发布标签构建分发包而非 tarball，以减少攻击风险。