« 扩展 Lua 的常量类型 | 返回首页 | ANSI escape code 及 Lua 封装 »

构建工具从 Make 到 Ninja

最近,我们把自研游戏引擎的构建工具从 GNU Make 迁移到了 Ninja

迁移动机是这样的:

我为引擎编写了最初的 Makefile ,它可以很好的工作在 MinGW / MacOSX / iOS 平台。把基本框架搭好以后,用起来也比较方便。但是,参与开发的同事一直有用 MSVC 开发的需求,而我们迟迟没有在 Makefile 的框架里增加 MSVC 的支持。用 MSVC 的同事一直在手工维护一个 MSVC 的项目。

渐渐的,同时维护 Makefile 和 MSVC 的工程成了一个负担。

实际上,现在惯用的方法都是用一个高阶的语言去描述项目构建流程,再翻译成不同平台下的构建脚本。即使用 GNU Make ,通常我们也是先用 Make 本身设计一个框架,在这个框架下去描述构建脚本,再让 Make 在不同平台下生成不同的流程。

如果不介意引入新的工具,那么 Autoconf ,CMake ,Premake 都可以解决这个问题。

我们的项目其实混用了不少构建工具。每个第三方库都直接使用它自己的构建流程。使用最多的是 CMake ,其次是 PreMake/GENie 。在这几年的使用过程中,我意识到想维护好 CMake 构建脚本是一件很困难的事。或者对使用的人来说,可以享受一键编译的方便,但编写和调试都是非常麻烦的。

我们的项目需求比较单一,在很长时间直接用 Make 维护两个平台的编译环境并不麻烦,开发成本远小于维护 CMake 脚本。但最近,想引入第三个开发环境(MSVC),有一些新的开发工作,所以就重新考虑这个问题了。

如果考虑把描述构建流程和实际的构建脚本分离,就没有必要坚持使用单个工具(GNU Make )。我更倾向于使用 Lua 来描述,毕竟我们项目的主体开发语言就是 Lua 。我们所有的开发人员都有丰富的 Lua 开发经验。Lua 比 Make 要容易用的多。

一旦不使用 Make 中那些用来生成构建流程的特性,Ninja 这种功能更少,解决问题更明确的工具就更合适。

Ninjia 的设计原则就是构建脚本易于人阅读(方便调试),但不易于人直接书写(方便机器解析)。同时,构建流程可以获得更高的效率。减少构建时间能直接提高开发效率。

我们使用了自己开发的 luamake 来生成 Ninja 脚本。相比 CMake 来说,Lua 对我们更熟悉,调试更方便;相比 PreMake ,我们自己维护的工具目的更纯粹,更聚焦于项目的需求。

Comments

xmake能完全解决依赖管理的问题,自带一个仓库而且引用第三方仓库都行,第三方仓库有vcpkg/anaconda/conan等等。不过他对lua语言有一定修改,语法不完全等价于lua5.1或者lua5.4,用类似lua来描述好一些。反正比cmake那套语法正常太多了,cmake纯反人类

请问这里只关注到构建工具吗?最近在写 C++ Project 的过程中遇到了依赖管理的问题,CMake 是能部分解决依赖管理问题的。C++ Project 肉眼可见的没有 Java 系的 Maven Central 或 Python 的 PyPi,搞依赖太麻烦了。

xmake 对于 Lua 5.4 的项目不太友好,它是 Lua JIT/5.1 的语法。如果项目里混合了 5.4 和 5.1 的 Lua 代码会比较糟糕。对于写惯 5.4 的人,也是回不去 5.1 的。

xmake 可以尝试一下,生态越来越齐全了。

同推荐XMake,它也是用Lua来写配置的,可以生成Makefile, ninja, VSProject, XCode

好早就关注这个库了,我认为它比CMake好用很多,而且已经开发很久,应该是比较成熟的。

最重要的一点是开源,这个比自己公司花费人力去做一个要合算得多。

可以考虑下xmake

坐等开源

"没有第三方库都直接使用它自己的构建流程", "没有"应该改成"每个"吧?

有个叫"xmake"的构建工具用的是Lua语法.

最近编译了一个用 ninja 的代码,用户体验就一个字——爽。比 make 好使太多

Post a comment

非这个主题相关的留言请到:留言本