快年底了，圣诞节前夕发个版，现代化的 c/c++的构建工具： xmake

[waruqi]

距离上个版本，一晃又快四个月过去了，这期间断断续续对xmake做了不少使用体验上的改进，并且修复了不少问题。

这个版本并没有加入太多新特性，主要对 c++20 modules 进行了实验性支持，目前支持 clang/msvc 编译器，但是由于 gcc 目前相关支持还没 merge 进 master，所以 xmake 暂时还没对齐支持，有兴趣的同学可以使用 clang/msvc 尝鲜下。

另外，这个版本新增了 socket.io 支持以及对应协程 io 的调度支持，为下个版本的远程编译，以及后续的分布式编译做准备。

关于明年的下个版本，我打算先支持上远程编译，比如可以在 win 上方便的远程编译运行 linux/macosx 程序，或者在 linux 上远程编译 win 程序，然后通过搭配 xmake-vscode/vs/sublime 等插件提高开发效率。

• 项目源码
• 官方文档

简介

XMake 是一个基于 Lua 的轻量级跨平台自动构建工具，支持在各种主流平台上构建项目

xmake 的目标是开发者更加关注于项目本身开发，简化项目的描述和构建，并且提供平台无关性，使得一次编写，随处构建

它跟 cmake、automake、premake 有点类似，但是机制不同，它默认不会去生成 IDE 相关的工程文件，采用直接编译，并且更加的方便易用 采用 lua 的工程描述语法更简洁直观，支持在大部分常用平台上进行构建，以及交叉编译

并且 xmake 提供了创建、配置、编译、打包、安装、卸载、运行等一些 actions，使得开发和构建更加的方便和流程化。

不仅如此，它还提供了许多更加高级的特性，例如插件扩展、脚本宏记录、批量打包、自动文档生成等等。。

工程描述示例

add_requires("libuv master", "ffmpeg", "zlib 1.20.*", "tbox >1.6.1")
target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_packages("libuv", "ffmpeg", "tbox", "zlib")

新特性介绍

c++20 modules

c++ modules 已经正式纳入了 c++20 草案，msvc 和 clang 也已经基本实现了对modules-ts的支持，随着 c++20 的脚步离我们越来越近，xmake 也开始对 c++modules 提前做好了支持。

目前 xmake 已经完全支持了 msvc/clang 的 modules-ts 构建实现，而对于 gcc，由于它的 cxx-modules 分支还在开发中，还没有正式进入 master，我看了下里面的 changelog，相关 flags 还在不断变动，感觉还没稳定下来，因此这里暂时还没对其进行支持。

关于 xmake 对 c++modules 的相关进展见：https://github.com/xmake-io/xmake/pull/569

Hello Module

关于 c++modules 的相关介绍我就不多说了，这边主要还是介绍下 xmake 下如何去构建 c++modules 项目，我们先来看一个简单的例子：

target("hello")
    set_kind("binary")
    add_files("src/*.cpp", "src/*.mpp") 

上面是一个支持构建 c++modules 文件的 xmake.lua 描述，其中hello.mpp就是模块文件：

#include <cstdio>
export module hello;
using namespace std;

export namespace hello {
    void say(const char* str) {
        printf("%s\n", str);
    }
}

而 main.cpp 是使用了 hello 模块的主程序：

import hello;

int main() {
    hello::say("hello module!");
    return 0;
}

接下来我们执行 xmake 来构建下这个程序吧：

ruki:hello ruki$ xmake 
[  0%]: ccache compiling.release src/hello.mpp
[ 50%]: ccache compiling.release src/main.cpp
[100%]: linking.release hello
build ok!

xmake 内部会去处理所有细节逻辑，对于开发者而言，仅仅是添加了模块文件*.mpp作为源文件而已。

关于更多详情，可以看下我的博客文章：https://tboox.org/cn/2019/12/21/xmake-update-v2.2.9/

模块接口文件

上文所述的*.mpp是 xmake 推荐的模块接口文件命名，其实各家编译器对于模块文件的默认后缀名都是不统一的，clang 下是*.cppm，而 msvc 下是*.ixx，这对于编写跨编译器统一的模块项目是非常不友好的， 因此这里参考了build2里面的推荐方式，采用统一的*.mpp后缀，来规范 xmake 下模块项目接口的命令。

当然，这也支持 xmake 推荐命名方式，而对于*.ixx, *.cppm等后缀名，xmake 也是完全兼容支持的，也可以直接添加到add_files中去。

其他例子

xmake 项目下还内置了不少跟 c++modules 相关的工程 examples，有兴趣的同学可以参考下：c++module examples

socket io

这块的接口初步已经实现，支持 lua 协程的 io 调度，实现高并发的 io 读写（后期还会同时支持进程、pipe 的调度支持），目前主要用于 xmake 自身的使用，用于为后续的远程编译和分布式编译做准备，所以暂时不开放用户自己使用，不过等后续完善后，会开放出来，用户也可以在自己的插件里面通过 socket io 做一些服务程序。

不过可能用户用到的场景不是很多，毕竟 xmake 只是个构建工具，很少会让用户自己去做 io 通信。

更新内容

新特性

• #569: 增加对 c++模块的实验性支持
• 添加xmake project -k xmakefile生成器
• 620: 添加全局~/.xmakerc.lua配置文件，对所有本地工程生效.
• 593: 添加core.base.socket模块，为下一步远程编译和分布式编译做准备。

改进

• #563: 重构构建逻辑，将特定语言的构建抽离到独立的 rules 中去
• #570: 改进 Qt 构建，将qt.application拆分成qt.widgetapp和qt.quickapp两个构建规则
• #576: 使用set_toolchain替代add_tools和set_tools，解决老接口使用歧义，提供更加易理解的设置方式
• 改进xmake create创建模板工程
• #589: 改进默认的构建任务数，充分利用 cpu core 来提速整体编译速度
• #598: 改进find_package支持在 macOS 上对.tbd 系统库文件的查找
• #615: 支持安装和使用其他 arch 和 ios 的 conan 包
• #629: 改进 hash.uuid 并且实现 uuid v4
• #639: 改进参数解析器支持-jN风格传参

Bugs 修复

• #567: 修复序列化对象时候出现的内存溢出问题
• #566: 修复安装远程依赖的链接顺序问题
• #565: 修复 vcpkg 包的运行 PATH 设置问题
• #597: 修复 xmake require 安装包时间过长问题
• #634: 修复 mode.coverage 构建规则，并且改进 flags 检测

[liang96]

支持大牛

[liang96]

对于已存在只能用 cmake 编译的项目，是否有办法改用 xmake 编译呢？

[waruqi]

@liang96 目前还不支持自动从 cmakelists 转换，需要自己手动移植下，不过从 xmake 生成 cmakelists 是支持的

[takemeh]

@waruqi 同好奇用 cmake 编译的库怎么加入依赖的？
这种库直接 cmake 编译的吗？ 还是现在不支持这种库呢？

[waruqi]

@takemeh 支持，xmake 有自己的远程包仓库，可以在里面描述好 cmake 库的构建规则，然后 xmake 里面追加依赖后，会自动拉取对应版本，下载然后调用 cmake 编译后，自动继承进来。。你可以看下： https://github.com/xmake-io/xmake-repo/blob/master/packages/p/pcre2/xmake.lua

当然，xmake 也支持用户自定义私有的分布式仓库，去中心化，也可以定义本地仓库，甚至没有仓库，直接在项目里面定义其他库的构建描述。具体可以看下文档： https://xmake.io/#/zh-cn/package/remote_package

[Cyshall]

个人觉得支持从 cmakelists 转换很重要阿。

[neilp]

必须膜拜

[waruqi]

@Cyshall 没时间搞 新项目可以试试 xmake

[wps353]

膜拜

[angryfish]

真心膜拜搞 c++的人们，javaer 低头路过

[mq4079]

ide 只用 clion，所以还是 cmake 香

[waruqi]

@mq4079 xmake 也提供 idea/clion/android studio 系列插件 vscode/sublime/vs 插件也有

[waruqi]

这里有个之前做的演示视频： https://asciinema.org/a/133693，不过有点年头了 = =

[edimetia3d]

我没仔细看文档, 总感觉写的不够诱人啊. 有几个问题. 我是 cmake 用户.
问题 1: 假如我刚入门, 这个项目如何吸引无基础的新用户呢? 或者说, 假如有后辈问我, 我为什么要推荐他从 xmake 入手,而不是 cmake 入手呢?
问题 2: 我为什么要从 cmake 迁移到 xmake 上, 有没有什么技术上的痛点是 xmake 才能解决的.
问题 3: xmake 有没有明确的推广计划? 比如找大公司背书, 或者抱项目的大腿, 我觉得当年 cmake 就是抱上了 kde 的大腿才稳住了不少人吧.

[waruqi]

@edimetia3d

问题 1: 这也是 xmake 亮点之一，就是描述语法直观简洁，可读性好，能够快速上手

另外 cmake 只是个生成工具，编译还需要依赖调用 ide/make 等工具，不同平台编译和生成行为都是有差异的，无形中会增加用户的学习成本

xmake 是直接编译，运行，调试，打包，安装，卸载一整套子命令系统，不依赖任何 make 和 ide

当然跟 vsvode, sublime, idea, clion, vs 的插件也都有提供

问题 2: xmake 正在努力解决 c/c++的依赖包痛点，提供更加方便一致的依赖包维护，除了像 cmake 那样支持 vcpkg, conan 等第三方包管理, xmake 还提供自己的包管理，目前支持 win, linux, macos, mingw, android,ios 的依赖包集成，当然前提是包本身代码也得支持

并且支持分布式去中心的多仓库管理，用户可以很方便的自建私有仓库

问题 3: 如果能找到大公司支持当然最好，目前阶段还没有，不过这里已经不少项目在用了，虽然不多，还有很多用户都是公司项目在用，这里不方便公开

目前的状态，确实比不过 cmake，毕竟 cmake 得生态已经很完善了，当初我做 xmake 也不是单纯为了替代 cmake，那不现实，主要是我不习惯 cmake 的写法和用法，对于不同平台的快速切换编译很繁琐，行为也不一致所以才自己整了一套。

所以，如果有兴趣的同学，可以尝试下，不一定要完全替换现有工程，比如一些新项目，或者临时的代码测试，用 xmake 整起来还是很方便的。

另外，后续版本我打算支持跨平台的 远程编译 和 分布式编译，也将会是很不错亮点特性。