构建系统讨论

构建系统讨论 我的上一篇博客文章对永久计算邮件列表产生了一些兴趣，特别是因为它与设计个人或永久计算构建系统有关。我想我应该快速概述 ../lua/civ 构建系统，并探索参与者所讨论的内容，以及我大脑中酝酿的有关 civ 包管理器的想法。作为参考，这里提供了构建系统。在大多数情况下，我不会给出有针对性的批评，而是列出我认为一个好的构建系统需要实现的目标。我的大部分批评将针对 bazel 和 Make：https://bazel.build Google 的构建系统，该系统可以实时增量或从头开始构建 Google 的所有软件。 ../lua/civ - 该项目的构建系统。 Kartik 的方法 LM Build System clib 看起来主要是小型 C 库和脚本的集合，可将它们直接集成到源代码中。 Make——无需介绍。构建系统或包管理器到底是什么？在我们讨论细节之前，重要的是回到基本事实：构建系统的作用是什么？曾经有一位刚从大学毕业的工程师向我询问一些与他正在处理的 CAD 文件相关的问题。他花了 5-10 分钟试图解释他的特定 CAD 工具的所有细节、某些表示形式如何难以编写脚本以及他如何解决它，等等。我对 CAD 几乎一无所知，因此对技术细节几乎没有帮助，但我确实问了他一个问题：你的输入是什么，你的输出是什么？带着这个问题，他彻底重新思考了这个问题。他很快开始理清他所形成的复杂网络，并开始讨论技术细节，让事情比他想象的更干净、更简单、更容易。对CAD一无所知的我只能微笑——但这已经足够了。那么什么是构建系统呢？ Civ 的答案是，它是一个程序，它以源代码（文件）、二进制文件（编译器）和配置（标志、配置文件）作为输入，并根据特定的文件夹结构输出文件、二进制文件和配置，然后可以在目标平台上执行。因此，一个好的构建系统的首要原则是：构建的每个阶段的所有输入和输出必须在某个地方是明确的。一个好的构建系统如何将输入转化为输出？第二个问题可能是更重要的问题：用户如何指定他们想要构建的内容，以及构建的不同部分（库、脚本、配置文件等）最终如何编织成整体？这就是像 Make 这样的程序惨败的地方 - Make 实际上是一个 shell 脚本的集合，采用了一种迟钝的、特定于平台的语法。它将每个“规则”定义为输入和输出的集合，但未能提供如何将它们拼接在一起的总体愿景。这是良好构建系统的下一个原则：必须能够以编程方式配置输入和输出以适应不同的目标系统。从本质上讲，一个好的构建系统在源代码和实际构建的程序之间提供了正确的抽象层 - 尽可能简单，但不能更简单。 Civ 的答案是这样的：将文件去向以及如何构建它们的决定权交给用户可以集中配置的东西 - 有效的构建库 - 它具有最小且定义良好的 API，但其内部结构可以交换到不同的平台。在 civ 中，这称为 sys hub 。例如 cc.luk（luk 是 lua 配置文件，一个全局变量略有不同的沙箱 lua 进程）包含将用户的 cc{hrd='foo.h'} 转换为发送到 sys/cc/build.lua 的对象的逻辑，该脚本实际执行来构建程序。这同时完成了两件事： 将用户对要构建的内容的规范与在目标体系结构上执行所需的特定输出结构分离。这使用户可以自由地构建源代码，但这对他们来说是最方便的，同时仍然可以在构建和安装后获得简洁的系统级标志（如 LD_LIBRARY_PATH）的好处。将需要构建的配置与构建过程分离 - 允许构建软件扩展到多个线程甚至多台机器（如果您重写 civ 协议以针对例如企业进行扩展）。这实际上是 Bazel（Google 的构建系统）做得很好的地方，但是虽然 Bazel 是一个巨大而复杂的软件，决定将 python（所有的东西）分叉为它的配置语言，但 civ 是用 1000 行 cmd 实用程序库编写的，它生成了一个封闭的 lua，使用大约 100 行 lua 库来解释配置。包管理 一个好的构建系统的最终质量是它能够连接到一个简单的包管理器上，这是我最想花时间的地方，因为它仅处于设计阶段。在 civ（或 bazel）中，当你创建时