xmake：以 Lua 描述构建，把包管理、交叉编译和缓存装进同一个工具

一个工具，四种职责

xmake 的定位很直接：用一份 xmake.lua 文件同时承担构建后端、项目生成器、包管理器和缓存层。README 里给出的公式是 Xmake = Build backend + Project Generator + Package Manager + [Remote|Distributed] Build + Cache，又用近似等式说明它相当于 Make/Ninja 加 CMake/Meson 加 Vcpkg/Conan 加 distcc 加 ccache/sccache。这个等式并不精确，但点明了它的野心。对开发者而言，这意味着不用再为每个项目拼装 CMake、Conan 和 ccache 三套配置。xmake 把编译、依赖拉取和缓存都收敛到同一个命令行入口，比如 xmake 直接构建，xmake f -p linux -a arm64 切换平台。这种一体化设计降低了入门成本，但也把复杂性集中到了 Lua 配置和 xmake 自身的行为上。

Lua 配置语法：简洁背后的表达力

xmake 的配置语法是 Lua 代码，而不是像 CMake 那样的自定义命令语言。一个最简单的目标只需要三行：target("console")、set_kind("binary")、add_files("src/*.c")。这比 CMake 的 add_executable 加 target_include_directories 简洁得多。Lua 的优势在于它是通用编程语言，可以在配置里写循环、条件、函数，甚至调用外部命令。但这也意味着配置不是声明式的，构建逻辑的执行顺序和副作用需要开发者自己管理。对于简单项目，xmake.lua 比 CMakeLists.txt 更容易读懂；对于复杂项目，Lua 的灵活性可能反而导致配置难以审查。README 强调语法“simple and readable”，但可读性取决于写配置的人是否自律。

包管理：xmake-repo 是核心依赖

xmake 内置包管理，通过 add_requires("tbox 1.6.*", "zlib", "libpng ~1.6") 声明依赖，版本号支持通配符和范围。它会自动下载、构建并链接依赖，省去手动管理 Vcpkg 或 Conan 的步骤。但这里的关键约束是官方仓库 xmake-repo 的覆盖范围。README 只提到 xmake-repo 是官方包仓库，没有列出具体包的数量或质量。依赖是否可用，完全取决于这个仓库的维护情况。如果你需要的库不在其中，就得自己写包描述，这比直接用 CMake 的 FetchContent 或 Vcpkg 的 portfile 更麻烦。所以采用 xmake 前，先查 xmake-repo 里有没有你需要的库，这是一个具体且必要的验证步骤。

平台与工具链：列表很长，但成熟度不均

README 列出的平台覆盖了 Windows、macOS、Linux、各种 BSD、Android、iOS、Wasm、Haiku、Harmony 甚至 Cross 通用交叉编译。工具链列表同样丰富，从 MSVC、clang、gcc 到 Go、Rust、Zig、Fortran、Cuda 等。这个列表展示了 xmake 的跨平台野心，但也带来一个问题：平台支持是分级的。像 Windows、Linux、macOS 这样的主流平台经过大量测试，而 Haiku、Harmony、AppleXROS 这类小众平台可能只有基础支持。交叉编译方面，xmake 声称有“智能分析交叉工具链信息”的能力，但具体如何智能、支持哪些工具链，README 没有展开。实际使用中，交叉编译的坑往往在系统库和链接器参数上，xmake 是否完全自动化处理，需要看文档或实测。

项目生成器与插件：不是替代 CMake，而是补充

xmake 不仅能直接构建，还能生成 Visual Studio 项目、Makefile、CMake 文件以及 compile_commands.json。这个能力让它可以作为现有工作流的一部分，而不是强制替代。比如你可以在 CI 里用 xmake 构建，同时生成 compile_commands.json 给 clangd 做代码补全。但注意，生成 CMake 文件并不意味着你能完全摆脱 CMake，生成的 CMake 可能只是薄封装，复杂项目仍需原生 CMake。xmake 的插件系统也支持扩展，比如 REPL 交互执行、远程编译、分布式编译和缓存。这些功能在 README 里只是罗列，没有深入说明配置方式。对于需要分布式构建的团队，xmake 的 remote build 和 distributed build 是亮点，但它们的部署复杂度可能不亚于配置一套单独的 distcc 集群。

安装与入门：脚本安装，依赖为零

xmake 的安装方式很简单，Linux/macOS 用 curl -fsSL https://xmake.io/shget.text | bash，Windows 用 PowerShell 的 irm https://xmake.io/psget.text | iex。也可以从源码构建或通过包管理器安装。README 强调 xmake“非常轻量，除标准库外无依赖”，这意味着安装后不会污染系统。这种零依赖设计降低了上手门槛，但也意味着 xmake 自己需要处理所有平台差异，比如编译器探测、路径处理、环境变量。如果某个平台上的行为有问题，你只能等官方修复，无法通过调整系统库来绕过。安装后，基本工作流是 xmake 构建、xmake run console 运行、xmake test 跑测试、xmake f -p android -a arm64 切换平台。这些命令直观，但配置选项的完整集合需要查阅文档。

维护与升级：活跃开发，但版本节奏快

仓库默认分支是 dev，最近一次提交在 2026 年 8 月，v3.1.1 是当前最新版。从 v3.0.9 到 v3.1.1 只隔了三个月，说明开发节奏很快。快速迭代的好处是功能更新及时，坏处是配置语法和包仓库可能有不兼容变更。xmake 采用 Apache-2.0 许可证，允许商用和修改，但如果你在内部二次开发，需要保留版权声明。升级成本方面，xmake.lua 的语法相对稳定，但新版本可能调整包管理行为或工具链默认值。建议在升级前查看 release notes，尤其是从 v3.0.x 到 v3.1.x 的变更。对于长期项目，锁版本或使用 vendored 安装可能是更稳妥的选择。

真正的替代方案：CMake 加 Vcpkg 与 Meson

xmake 最直接的替代是 CMake 加 Vcpkg 的组合。CMake 是事实标准，生态庞大，几乎所有库都提供 CMake 支持。Vcpkg 则提供大量预编译包，且与 CMake 集成成熟。这个组合的缺点是配置繁琐，需要维护 CMakeLists.txt 和 vcpkg.json 两份文件。另一个替代是 Meson，它用 Python 风格的 DSL，配置比 CMake 简洁，但包管理依赖 WrapDB，覆盖范围不如 Vcpkg。xmake 的差异化在于把构建和包管理整合到 Lua 中，适合喜欢脚本化配置的开发者。如果你已经熟悉 CMake，切换成本可能高于收益；如果你是新手，xmake 的简单语法可能比 CMake 更友好。但生态成熟度和社区资源方面，CMake 仍然领先。

编辑结论

xmake 适合那些愿意用 Lua 写构建逻辑、需要跨平台且希望单一工具覆盖依赖管理和编译的 C/C++ 项目。它尤其适合个人开发者和小型团队，因为安装简单、配置直观，且内置包管理省去单独配置 Vcpkg 或 Conan 的麻烦。不适合已有大量 CMake 投资、依赖复杂自定义生成器或需要严格企业级支持的大型项目。采用前应验证三件事：你需要的依赖是否在 xmake-repo 官方仓库中，团队是否接受 Lua 语法，以及你的目标平台（如 Harmony、Wasm）在 xmake 中的成熟度是否满足生产要求。xmake 的边界在于它的包仓库和工具链支持仍在快速演进，生产环境使用前必须检查当前版本的实际行为。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes