这是一个创建于 2120 天前的主题，其中的信息可能已经有所发展或是发生改变。
距离上个版本，一晃又快四个月过去了，这期间断断续续对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 修复
 | 1 liang96 2019-12-23 07:56:34 +08:00 via Android 支持大牛 |
| 2 liang96 2019-12-23 08:01:35 +08:00 via Android 对于已存在只能用 cmake 编译的项目，是否有办法改用 xmake 编译呢？ |
 | 3 waruqi OP @liang96 目前还不支持自动从 cmakelists 转换，需要自己手动移植下，不过从 xmake 生成 cmakelists 是支持的 |
| 5 waruqi OP @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 |
 | 6 Cyshall 2019-12-23 09:10:59 +08:00 个人觉得支持从 cmakelists 转换很重要阿。 |
 | 7 neilp 2019-12-23 09:13:28 +08:00 必须膜拜 |
 | 9 wps353 2019-12-23 10:29:01 +08:00 膜拜 |
 | 10 GBdG6clg2Jy17ua5 2019-12-23 10:57:26 +08:00 真心膜拜搞 c++的人们，javaer 低头路过 |
 | 11 mq4079 2019-12-23 11:51:44 +08:00 ide 只用 clion，所以还是 cmake 香 |
| 12 waruqi OP @mq4079 xmake 也提供 idea/clion/android studio 系列插件 vscode/sublime/vs 插件也有 |
| 13 waruqi OP 这里有个之前做的演示视频： https://asciinema.org/a/133693，不过有点年头了 = = |
 | 14 edimetia3d 2019-12-23 20:05:55 +08:00 我没仔细看文档, 总感觉写的不够诱人啊. 有几个问题. 我是 cmake 用户. 问题 1: 假如我刚入门, 这个项目如何吸引无基础的新用户呢? 或者说, 假如有后辈问我, 我为什么要推荐他从 xmake 入手,而不是 cmake 入手呢? 问题 2: 我为什么要从 cmake 迁移到 xmake 上, 有没有什么技术上的痛点是 xmake 才能解决的. 问题 3: xmake 有没有明确的推广计划? 比如找大公司背书, 或者抱项目的大腿, 我觉得当年 cmake 就是抱上了 kde 的大腿才稳住了不少人吧. |
| 15 waruqi OP  1 @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 整起来还是很方便的。 另外，后续版本我打算支持跨平台的 远程编译 和 分布式编译，也将会是很不错亮点特性。 |
Select Language