距离上个版本,一晃又快四个月过去了,这期间断断续续对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++ 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
关于 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
这块的接口初步已经实现,支持 lua 协程的 io 调度,实现高并发的 io 读写(后期还会同时支持进程、pipe 的调度支持),目前主要用于 xmake 自身的使用,用于为后续的远程编译和分布式编译做准备,所以暂时不开放用户自己使用,不过等后续完善后,会开放出来,用户也可以在自己的插件里面通过 socket io 做一些服务程序。
不过可能用户用到的场景不是很多,毕竟 xmake 只是个构建工具,很少会让用户自己去做 io 通信。
xmake project -k xmakefile
生成器~/.xmakerc.lua
配置文件,对所有本地工程生效.core.base.socket
模块,为下一步远程编译和分布式编译做准备。qt.application
拆分成qt.widgetapp
和qt.quickapp
两个构建规则set_toolchain
替代add_tools
和set_tools
,解决老接口使用歧义,提供更加易理解的设置方式xmake create
创建模板工程find_package
支持在 macOS 上对.tbd 系统库文件的查找-jN
风格传参 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
angryfish 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 @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 整起来还是很方便的。 另外,后续版本我打算支持跨平台的 远程编译 和 分布式编译,也将会是很不错亮点特性。 |