Lua 构建系统

wiki

• SCons 类系统
  • LuaBuildBou - 依赖构建系统（有点像 SCons）
  • [Lake] Bou 已经发展并更名为 Lake
  • [primemover] - 小型、可移植、易于部署的依赖构建系统（有点像 SCons）
  • [Bam] - （类似 SCons）
  • [LuaIBS] - 用 Lua 和 C 编写的 make 替代品，使用 LuaFileSystem
  • [Meique] - 用 Lua 和 C++ 编写的 scons 类工具
  • [Sweet Build] - 用 C++ 和 Lua 编写的构建工具。
  • [moonmake]
  • [tmake] - 用 C++ 编写的构建工具，使用 lua 作为配置文件。
  • [flake] - 具有 scons 类界面的 FRP 启发式构建工具
  • [xmake] - 基于 Lua 的跨平台构建工具
• 构建脚本生成器（如 Autotools 和 CMake）
  • [premake] - 构建脚本生成器（类似 CMake，但使用 Lua 作为配置语言）
  • [xmake] - 基于 Lua 的跨平台构建工具，构建脚本生成器作为插件
  • [Hamster] - 用于 Lua 的构建脚本生成器，其 API 来自 [scons]。它可以生成 Makefiles（GNU/BSD/nmake），使用 scons 构建，或不使用任何外部工具构建。
  • [makebuild.lua] 简陋的 Lua makefile 生成器，代码少于 100 行。
  • [9] - rockspec 到 Makefile 转换器的概念验证
  • [bang] - 用 Lua/LuaX 可脚本化的 Ninja 文件生成器
• 其他
  • [jamplus] - Perforce Jam 的衍生产品，具有各种增强功能，例如输出 Visual Studio IDE、Xcode 和 CodeBlocks 项目文件。它嵌入了一个最小的 LuaPlus? [10]。
  • [tundra] - Lua 配置语言生成一个 DAG，由支持快速增量构建的多线程 C 构建器使用。 注释：[11][12][13]
  • [luacc] - 将多个 Lua 源文件合并成一个。它是一个独立的单文件 Lua 脚本
• CPAN 类系统
  • LuaRocks - 部署 Lua 模块，包括网络获取、自动构建、安装和管理（类似于 Perl CPAN）
  • [luapower] - 模块使用简单的 shell 脚本构建，直接调用 gcc
• 记忆化构建系统（如 fabricate、memoize.py、fbuild 等）
  • [lua-mbuild]
• 另请参阅
  • [CMake 使用 Lua 的实验] - 用 Lua 替换 CMake 语言的原型。 [更新：2012-08]

以下是一些构建系统，它们不一定是用 Lua 实现的，但已被用于构建与 Lua 相关的代码

• Make（包括 [GNU Make]） - Lua（和 LuaJit）的标准发行版只包含一个 Makefile。其他示例包括 [murgaLua]。
• [autotools] - 在许多地方使用，例如 [LOVE]。
• [JamPlus] - 由 [LuaPlus] 使用
• [tecmake] - 已用于一些事情，例如 [IUP] 和 [LuaBinaries]。
• 另请参阅 LuaDistributions（例如 LuaRocks）、BuildingLua 和 BuildingModules。

此类构建自动化系统 ([1]) 涵盖以下主题

• 编译代码或其他文件。这涉及几个部分
  • 存在一些配置语言，用于定义要构建的内容以及构建顺序。这可以是 makefile 的形式。它可以用特定于问题域的有限语言表达，但由于可能需要对编译内容和方式做出决策，因此一些通用语言功能很有用，例如变量、控制结构、函数/宏以及字符串/列表操作。一些系统使用 Python（如 SCons）或 Lua 来实现这一点。即使你的构建系统没有使用 Lua 作为配置语言，你仍然可以从其中调用 Lua 解释器。
  • 可能存在一些将配置语言中的高级构建描述（例如，从 C 文件列表编译共享库）转换为要运行的实际命令（带有开关的编译器命令行）的方法。这可能需要了解每个支持的工具链，这些知识可能内置在构建工具中或由用户定义。一些更简单的构建系统（例如 make）不直接提供这些知识，而是让用户输入低级构建描述。
  • 存在一些调度命令的方法，包括确保命令根据依赖项按特定顺序运行，将作业排队以在不同的 CPU 内核或机器上并行运行，如果目标是最新的（基于时间戳或校验和）则省略命令，以及检查错误结果。这通常与命令的实际运行紧密耦合，例如通过 os.execute 或一些更高级的特定于平台的进程控制机制或作业处理器。命令可以在配置语言（如 SCons）中调用。或者，这项工作可以卸载到另一个现有的工具，就像“makefile 生成器”（如 Automake、CMake 或 premake）那样，它们生成例如 makefile、ninja 构建描述或 msbuild 描述，以便在后续的构建步骤中单独使用。如果依赖项发生变化，可能需要重新生成 makefile，并且有一些方法可以将此插入 makefile 本身。依赖项树可能在某种程度上需要动态确定（例如 C 包含文件）。
  • 可能存在一些平台检测方法（例如检测主机编译器、库和可用符号），例如 autoconf。此信息用于“翻译高级构建描述”。有时它作为构建过程的一部分运行，或者（就像在 autoconf 中）它可能是在构建过程之前运行的步骤，并且在增量构建期间不会重新运行，假设平台没有改变。作业处理器可能需要为此执行诸如在主机平台上测试编译之类的事情（假设不是交叉编译到不同的目标平台）。
• 运行测试（make test）、部署（make install）和打包（例如 .deb）。
• 部署和/或编译依赖项——例如 LuaRocks、LuaDist 中的部署工具和 CPAN。

关注点包括

• 构建系统的部署简便性。如果构建系统通常是预安装的（例如 make），或者易于安装（apt-get install cmake），或者可能占用空间小且易于部署，甚至捆绑在你的包中（例如 [primemover]），这将很方便。
• 熟悉度。学习、调试或维护一个不熟悉、非标准、有 bug、不灵活的构建系统并不有趣。编写自己的构建系统很诱人，但代价不菲。
• 平台支持。该工具是否知道如何在你的平台和工具链上构建？
• 通用性。如果你的构建只调用自定义命令（例如构建网页或图像而不是 C 代码），那么在定义自己的任意规则（例如在 make 中）方面的便利性比拥有广泛的内置工具链支持更重要。
• 速度。增量构建的速度如何？是否支持并行构建？预编译头文件？
• 如果需要支持多种平台，则支持平台检测（如 autoconf）。
• 配置语言。
• IDE 集成，例如在 premake、CMake 或更小程度上 [SCons] 中。
• 构建过程的可靠性。