会考虑使用xmake吗？

[vkensou]

我可以理解最初为什么没有用xmake，因为引擎开始做的时候还没有xmake。
但现在xmake已经非常成熟了。再开发一个luamake等于重新实现了一遍xmake、再把xmake遇到的坑重新踩一遍。
重新开发维护一个编译系统会牵扯极大的精力。

[vkensou]

又查了一下，是xmake先出来的。
也许是因为你们一开始做的时候认为自己开发维护一个简单的编译构建系统很容易，不过ant开源之后暴露除了不少问题，后续再要修这些问题的话，恐怕工作量不小。

[cloudwu]

为单一项目修问题比为通用项目修问题要容易的多。xmake 问题也不少，一旦遇到新需求新问题要修会麻烦的多。

如果你查 luamake 的更新历史，就会发现是一路为这个项目改过来的。问题是收敛的。

[cloudwu]

不觉得 xmake 有任何优势，反而在动态生成代码方面及其难用。

luamake 目前不是一个通用方案，它就是为这个项目维护的。Ant 一开始就是直接用的 make ，切换到 luamake 是因为这是综合成本更小的方案。

我个人觉得 luamake 的学习成本也是小于 xmake 的。一般用户并不需要学习怎么写脚本，最多拷贝一下已有的脚本改。

[actboy168]

最初确实考虑过使用xmake，如果你去翻看xmake的issue应该能看到我提的一些issue。这就是调研xmake时留下的一些记录。我不想在这里陈诉为什么xmake不好。

但至少目前的构建系统包括不仅限于xmake,cmake，都非常复杂，无论是学习还是维护的成本都非常高。这成本甚至比自己实现一个构建系统都要高。

你可以尝试用xmake来写ant的构建脚本，相信你会对这个问题有更深刻的理解。

[vkensou]

我只是觉得能用成熟方案更省精力，同时也能让社区更广泛的参与进来。C/C++的构建系统实在是太多了，都喜欢造轮子。

[cloudwu]

我看到的绝大多数需要构建的项目，社区贡献者贡献的都是代码。很少有额外的人维护构建脚本的。

pr 中需要修改的往往也只是照葫芦画瓢增减一两行。

xmake 的项目基本没见过。cmake 项目，如果不是原作者自己动手，修改的人改起来基本是乱来。

[cloudwu]

关于“成熟方案”，imgui 作者就这样抱怨：

I have 21 open pull-requests suggesting to add some Cmake file to dear imgui examples or main lib, and every one of them seems to have an issue when I try it.

我的看法是：构建系统没有通用的成熟方案。不同的人更难在怎么用构建系统上达成一致，比在 c++ 编码中找到一个大家都达成共识的编码规范更难。所以这部份是难以共同创作的。

对于特定项目。会用就够了，不需要会写。

[sniper00]

使用 rust cc build 如何, 很成熟的 跨平台编译 C/Cpp代码的工具。

https://docs.rs/cc/latest/cc/struct.Build.html

A builder for compilation of a native library.

A Build is the main type of the cc crate and is used to control all the various configuration options and such of a compile. You’ll find more documentation on each method itself.

[constly]

构建是一方面。至少还要考虑的是，ant底层基于ecs，需要在构建时动态生成一些c++代码，要考虑新的构建方案在这方面支持得怎么样

[constly]

我觉得luamake还是挺直观简洁的。在使用过程中，可以很明显感受到她是依据ant的技术特点 专门打造的构建系统。

在实际开发中，大家关注的应该都是自己模块的构建脚本应该怎么写，这个用luamake是非常方便的。

至于其他的，开发人员不用操心了，引擎自己会处理好。就好比使用UE或者Unity时，开发者也不太有需求去改引擎的构建脚本一样的。
只是说目前ant的构建还不是很成熟稳定，这个需要一些时间。

就像上面说的那样，任何提议换构建系统的， 都可以先自己去尝试用新的构建系统编译ant，看看好不好写~
只有拿出具体的实践数据才有可能说服官方，不然就是在浪费时间和精力。