Xmake v2.7.3 发布，包组件和 C++ 模块增量构建支持

OSC编辑部系列直播：开源世界当中，到底存不存在“白嫖”?>>>>>

Xmake 是一个基于 Lua 的轻量级跨平台构建工具。

它非常的轻量，没有任何依赖，因为它内置了 Lua 运行时。

它使用 xmake.lua 维护项目构建，相比 makefile/CMakeLists.txt，配置语法更加简洁直观，对新手非常友好，短时间内就能快速入门，能够让用户把更多的精力集中在实际的项目开发上。

我们能够使用它像 Make/Ninja 那样可以直接编译项目，也可以像 CMake/Meson 那样生成工程文件，另外它还有内置的包管理系统来帮助用户解决 C/C++ 依赖库的集成使用问题。

目前，Xmake 主要用于 C/C++ 项目的构建，但是同时也支持其他 native 语言的构建，可以实现跟 C/C++ 进行混合编译，同时编译速度也是非常的快，可以跟 Ninja 持平。

 Xmake = Build backend + Project Generator + Package Manager + [Remote|Distributed] Build + Cache

尽管不是很准确，但我们还是可以把 Xmake 按下面的方式来理解：

 Xmake ~= Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache

项目源码
官方文档
入门课程

新特性介绍

包组件支持

背景简介

这个新特性主要用于实现从一个 C/C++ 包中集成特定的子库，一般用于一些比较大的包中的库组件集成。

因为这种包里面提供了很多的子库，但不是每个子库用户都需要，全部链接反而有可能会出问题。

尽管，之前的版本也能够支持子库选择的特性，例如：

 add_requires("sfml~foo", {configs = {graphics = true, window = true}}) add_requires("sfml~bar", {configs = {network = true}})  target("foo")     set_kind("binary")     add_packages("sfml~foo")  target("bar")     set_kind("binary")     add_packages("sfml~bar")

这是通过每个包的自定义配置来实现的，但这种方式会存在一些问题：

sfml~foo 和 sfml~bar 会作为两个独立的包，重复安装，占用双倍的磁盘空间
也会重复编译一些共用代码，影响安装效率
如果一个目标同时依赖了 sfml~foo 和 sfml~bar，会存在链接冲突

如果是对于 boost 这种超大包的集成，重复编译和磁盘占用的影响会非常大，如果在子库组合非常多的情况下，甚至会导致超过 N 倍的磁盘占用。

为了解决这个问题，Xmake 新增了包组件模式，它提供了以下一些好处：

仅仅一次编译安装，任意多个组件快速集成，极大提升安装效率，减少磁盘占用
组件抽象化，跨编译器和平台，用户不需要关心如何配置每个子库之间链接顺序依赖
使用更加方便

更多背景详情见：#2636

使用包组件

对于用户，使用包组件是非常方便的，因为用户是不需要维护包的，只要使用的包，它配置了相关的组件集，我们就可以快速集成和使用它，例如：

 add_requires("sfml")  target("foo")     set_kind("binary")     add_packages("sfml", {components = "graphics"})  target("bar")     set_kind("binary")     add_packages("sfml", {components = "network"})

查看包组件

那么，如何知道指定的包提供了哪些组件呢？我们可以通过执行下面的命令查看：

 $ xrepo info sfml The package info of project:     require(sfml):       -> description: Simple and Fast Multimedia Library       -> version: 2.5.1       ...       -> components:          -> system:          -> graphics: system, window          -> window: system          -> audio: system          -> network: system

包组件配置

如果你是包的维护者，想要将一个包增加组件支持，那么需要通过下面两个接口来完成包组件的配置：

add_components: 添加包组件列表
on_component: 配置每个包组件

包组件的链接配置

大多数情况下，包组件只需要配置它自己的一些子链接信息，例如：

 package("sfml")     add_components("graphics")     add_components("audio", "network", "window")     add_components("system")      on_component("graphics", function (package, component)         local e = package:config("shared") and "" or "-s"         component:add("links", "sfml-graphics" .. e)         if package:is_plat("windows", "mingw") and not package:config("shared") then             component:add("links", "freetype")             component:add("syslinks", "opengl32", "gdi32", "user32", "advapi32")         end     end)      on_component("window", function (package, component)         local e = package:config("shared") and "" or "-s"         component:add("links", "sfml-window" .. e)         if package:is_plat("windows", "mingw") and not package:config("shared") then             component:add("syslinks", "opengl32", "gdi32", "user32", "advapi32")         end     end)      ...

上面是一个不完整的包配置，我仅仅摘取一部分跟包组件相关的配置。

一个关于包组件的配置和使用的完整例子见：components example

配置组件的编译信息

我们不仅可以配置每个组件的链接信息，还有 includedirs, defines 等等编译信息，我们也可以对每个组件单独配置。

 package("sfml")     on_component("graphics", function (package, component)         package:add("defines", "TEST")     end)

配置组件依赖

 package("sfml")     add_components("graphics")     add_components("audio", "network", "window")     add_components("system")      on_component("graphics", function (package, component)           component:add("deps", "window", "system")     end)

上面的配置，告诉包，我们的 graphics 组件还会额外依赖 window 和 system 两个组件。

因此，在用户端，我们对 graphics 的组件使用，可以从

     add_packages("sfml", {components = {"graphics", "window", "system"})

简化为：

     add_packages("sfml", {components = "graphics")

因为，只要我们开启了 graphics 组件，它也会自动启用依赖的 window 和 system 组件，并且自动保证链接顺序正确。

另外，我们也可以通过 add_components("graphics", {deps = {"window", "system"}}) 来配置组件依赖关系。

从系统库中查找组件

我们知道，在包配置中，配置 add_extsources 可以改进包在系统中的查找，比如从 apt/pacman 等系统包管理器中找库。

当然，我们也可以让每个组件也能通过 extsources 配置，去优先从系统库中找到它们。

例如，sfml 包，它在 homebrew 中其实也是组件化的，我们完全可以让包从系统库中，找到对应的每个组件，而不需要每次源码安装它们。

 Xmake ~= Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache 0

我们只需要，对每个组件配置它的 extsources：

 Xmake ~= Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache 1

默认的全局组件配置

除了通过指定组件名的方式，配置特定组件，如果我们没有指定组件名，默认就是全局配置所有组件。

 Xmake ~= Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache 2

当然，我们也可以通过下面的方式，指定配置 graphics 组件，剩下的组件通过默认的全局配置接口进行配置：

 Xmake ~= Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache 3

C++ 模块构建改进

增量构建支持

原本以为 Xmake 对 C++ 模块已经支持的比较完善了，后来才发现，它的增量编译还无法正常工作。

因此，这个版本 Xmake 对 C++ 模块的增量编译也做了很好的支持，尽管支持过程还是花了很多精力的。

我分析了下，各家的编译器对生成带模块的 include 依赖信息格式（*.d），差异还是非常大的。

gcc 的格式最复杂，不过我还是将它支持上了。

 Xmake ~= Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache 4

clang 的格式兼容性最好，没有做任何特殊改动就支持了。

 Xmake ~= Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache 5

msvc 的格式扩展性比较好，解析和支持起来比较方便：

 Xmake ~= Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache 6

循环依赖检测支持

由于模块之间是存在依赖关系的，因此如果有几个模块之间存在循环依赖引用，那么是无法编译通过的。

但是之前的版本中，Xmake 无法检测到这种情况，遇到循环依赖，编译就会卡死，没有任何提示信息，这对用户非常不友好。

而新版本中，我们对这种情况做了改进，增加了模块的循环依赖检测，编译时候会出现以下错误提示，方便用户定位问题：

 Xmake ~= Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache 7

更加 LSP 友好的语法格式

我们默认约定的域配置语法，尽管非常简洁，但是对自动格式化缩进和 IDE 不是很友好，如果你格式化配置，缩进就完全错位了。

 Xmake ~= Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache 8

另外，如果两个 target 之间配置了一些全局的配置，那么它不能自动结束当前 target 作用域，用户需要显式调用 target_end()。

 Xmake ~= Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache 9

虽然，上面我们提到，可以使用 do end 模式来解决自动缩进问题，但是需要 target_end() 的问题还是存在。

 add_requires("sfml~foo", {configs = {graphics = true, window = true}}) add_requires("sfml~bar", {configs = {network = true}})  target("foo")     set_kind("binary")     add_packages("sfml~foo")  target("bar")     set_kind("binary")     add_packages("sfml~bar") 0

因此，在新版本中，我们提供了一种更好的可选域配置语法，来解决自动缩进，target 域隔离问题，例如：

 add_requires("sfml~foo", {configs = {graphics = true, window = true}}) add_requires("sfml~bar", {configs = {network = true}})  target("foo")     set_kind("binary")     add_packages("sfml~foo")  target("bar")     set_kind("binary")     add_packages("sfml~bar") 1

foo 和 bar 两个域是完全隔离的，我们即使在它们中间配置其他设置，也不会影响它们，另外，它还对 LSP 非常友好，即使一键格式化，也不会导致缩进混乱。

注：这仅仅只是一只可选的扩展语法，现有的配置语法还是完全支持的，用户可以根据自己的需求喜好，来选择合适的配置语法。

为特定编译器添加 flags

使用 add_cflags, add_cxxflags 等接口配置的值，通常都是跟编译器相关的，尽管 Xmake 也提供了自动检测和映射机制，即使设置了当前编译器不支持的 flags，Xmake 也能够自动忽略它，但是还是会有警告提示。

新版本中，我们改进了所有 flags 添加接口，可以仅仅对特定编译器指定 flags，来避免额外的警告，例如：

 add_requires("sfml~foo", {configs = {graphics = true, window = true}}) add_requires("sfml~bar", {configs = {network = true}})  target("foo")     set_kind("binary")     add_packages("sfml~foo")  target("bar")     set_kind("binary")     add_packages("sfml~bar") 2

或者：

 add_requires("sfml~foo", {configs = {graphics = true, window = true}}) add_requires("sfml~bar", {configs = {network = true}})  target("foo")     set_kind("binary")     add_packages("sfml~foo")  target("bar")     set_kind("binary")     add_packages("sfml~bar") 3

注：不仅仅是编译flags，对 add_ldflags 等链接 flags，也是同样生效的。

renderdoc 调试器支持

感谢 @SirLynix 贡献了这个很棒的特性，它可以让 Xmake 直接加载 renderdoc 去调试一些图形渲染程序。

使用非常简单，我们先确保安装了 renderdoc，然后配置调试器为 renderdoc，加载调试运行：

 add_requires("sfml~foo", {configs = {graphics = true, window = true}}) add_requires("sfml~bar", {configs = {network = true}})  target("foo")     set_kind("binary")     add_packages("sfml~foo")  target("bar")     set_kind("binary")     add_packages("sfml~bar") 4

具体使用效果如下：

新增 C++ 异常接口配置

Xmake 新增了一个 set_exceptions 抽象化配置接口，我们可以通过这个配置，配置启用和禁用 C++/Objc 的异常。

通常，如果我们通过 add_cxxflags 接口去配置它们，需要根据不同的平台，编译器分别处理它们，非常繁琐。

例如：

 add_requires("sfml~foo", {configs = {graphics = true, window = true}}) add_requires("sfml~bar", {configs = {network = true}})  target("foo")     set_kind("binary")     add_packages("sfml~foo")  target("bar")     set_kind("binary")     add_packages("sfml~bar") 5

而通过这个接口，我们就可以抽象化成编译器无关的方式去配置它们。

开启 C++ 异常:

 add_requires("sfml~foo", {configs = {graphics = true, window = true}}) add_requires("sfml~bar", {configs = {network = true}})  target("foo")     set_kind("binary")     add_packages("sfml~foo")  target("bar")     set_kind("binary")     add_packages("sfml~bar") 6

禁用 C++ 异常:

 add_requires("sfml~foo", {configs = {graphics = true, window = true}}) add_requires("sfml~bar", {configs = {network = true}})  target("foo")     set_kind("binary")     add_packages("sfml~foo")  target("bar")     set_kind("binary")     add_packages("sfml~bar") 7

我们也可以同时配置开启 objc 异常。

 add_requires("sfml~foo", {configs = {graphics = true, window = true}}) add_requires("sfml~bar", {configs = {network = true}})  target("foo")     set_kind("binary")     add_packages("sfml~foo")  target("bar")     set_kind("binary")     add_packages("sfml~bar") 8

或者禁用它们。

 add_requires("sfml~foo", {configs = {graphics = true, window = true}}) add_requires("sfml~bar", {configs = {network = true}})  target("foo")     set_kind("binary")     add_packages("sfml~foo")  target("bar")     set_kind("binary")     add_packages("sfml~bar") 9

Xmake 会在内部自动根据不同的编译器，去适配对应的 flags。

支持 ispc 编译规则

Xmake 新增了 ipsc 编译器内置规则支持，非常感谢 @star-hengxing 的贡献，具体使用方式如下：

 add_requires("sfml")  target("foo")     set_kind("binary")     add_packages("sfml", {components = "graphics"})  target("bar")     set_kind("binary")     add_packages("sfml", {components = "network"}) 0

支持 msvc 的 armasm 编译器

之前的版本，Xmake 增加了 Windows ARM 的初步支持，但是对 asm 编译还没有很好的支持，因此这个版本，我们继续完善 Windows ARM 的支持。

对 msvc 的 armasm.exe 和 armasm64.exe 都支持上了。

另外，我们也改进了包对 Windows ARM 平台的交叉编译支持。

新增 gnu-rm 构建规则

Xmake 也新增了一个使用 gnu-rm 工具链去构建嵌入式项目的规则和例子工程，非常感谢 @JacobPeng 的贡献。

 add_requires("sfml")  target("foo")     set_kind("binary")     add_packages("sfml", {components = "graphics"})  target("bar")     set_kind("binary")     add_packages("sfml", {components = "network"}) 1