构建工具从 Make 到 Ninja

云风 2021-05-08 17:44

最近,我们把自研游戏引擎的构建工具从 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 ,我们自己维护的工具目的更纯粹,更聚焦于项目的需求。

[返回] [原文链接]