构建工具从 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
Posted by: xlala | (9) July 7, 2021 01:34 PM
Posted by: tison | (8) June 28, 2021 03:49 PM
Posted by: Cloud | (7) May 21, 2021 04:46 PM
Posted by: 涵曦 | (6) May 21, 2021 02:46 PM
Posted by: colin | (5) May 16, 2021 09:25 AM
Posted by: YH | (4) May 15, 2021 02:11 PM
Posted by: perty | (3) May 10, 2021 09:41 AM
Posted by: dwing | (2) May 8, 2021 05:01 PM
Posted by: James | (1) May 8, 2021 04:52 PM