浅析鸿蒙系统的 Gn 与 Ninja（一）

72次阅读

共计 2225 个字符，预计需要花费 6 分钟才能阅读完成。

导读	鸿蒙系统的编译构建是基于 Gn 和 Ninja 完成的，那么 Gn 和 Ninjia 有什么关系呢? 具体又是如何工作的呢? 想必大多数热衷于应用开发的同学都还没有深究过，那么今天就借此机会带着大家扒一扒 Gn 和 Ninja。

我们先来说说 Ninja 吧!

Ninja 是借由 Google Chrome 项目而诞生的一个构建工具，它的诞生目标是为了速度。换句话说，在 Google Chrome 项目的开发过程中，开发者们认为同类型的其它构建工具不给力，所以才会考虑重新开发更高效的工具。要说同类型，那么不得不提构建界的老大哥 make !make 即 GNU Make，一个用于决定如何使用命令完成最终目标构建的程序。

在这里强调 make 的 3 个特性：

make 只是一个通用程序，它不知道如何具体的完成目标的构建工作
make 需要 makefile 中的描述来决定目标构建的具体方案
make 需要借助其它工具 (如：gcc) 才能执行方案，最终完成工作

这是不是跑题了! 不是说好的讨论 Ninja 吗? 怎么扯到 make 上去了?!

因为 Ninja 可以看作是一个更好的 make ! 而大多数同学都熟悉 make，所以通过对比 make 学习 Ninja 是一个非常好的选择! 上述关于 make 的 3 个特性对于 Ninjia 同样适用(理论上，make 有的 Ninjia 都有，并且更好!)。那么，是不是得先学习 make 再学习 Ninja 呢? 我觉得倒也不是! 毕竟我们最终还是在鸿蒙上做应用开发，编译构建系统只需要大体了解即可。

Ninja 的用法!

test.c 是一个简单的 Hello World 程序，用于打印一个字符串和头文件 test.h 中常量 CONST 的值。

根据 C 程序的编译方式可知：

在预处理阶段 test.h 中的代码直接嵌入 test.c 中(头文件 .h 最终成为源文件 .c 的一部分)

test.c 编译后得到目标文件 test.o

test.o 链接后得到最终的可执行程序 test.out

各个文件在编译过程中有明显的上下游关系，即：上游文件影响或者产生下游文件。

上图即描述了编译过程，同时也反映了这样一个事实：任何一个文件被改动时只可能影响下游文件，而不会影响上游文件。如：test.c 被修改了，那么可能导致编译得到 test.o 发生改变，进而导致最终的可执行程序 test.out 改变。因此，当 test.c 被修改时，那么应该重新触发编译和链接这两个动作。

看到这里，有同学可能存在这样的疑问：怎么知道文件已经被修改了并触发相应动作呢?

其实很简单，可以根据文件修改时间判断呀! 目前几乎主流的文件系统都会记录文件被修改的时间，所以结合文件的上下游关系可知：上游文件被修改的时间应该总是小于等于下游文件被修改的时间。这样，只需要遍历一次上面的构建图就可以知道执行哪些动作产生最终可执行程序了。

接下来思考这样一个问题：如何向构建工具 Ninja 描述构建图?

Ninja 的本质是一种通用程序。既然是程序，那么擅长的必然是处理结构化文本! 因此，可以用结构化文本 (Ninja 脚本) 来描述构建图。

下面直接上代码!

解读：

1. Ninja 脚本中的 build 语句描述构建图中的一个文件上下游关系。如：build test.o cc test.c 指明 test.o 由 test.c 通过规则 cc 而构建，test.c 在构建图中位于 test.o 的上游，从 test.c 到 test.o 需要执行的动作通过规则 cc 定义。Ninja 通过判断上下游文件的修改时间决定是否执行规则中定义的动作。多个 build 语句共同描述一个编译构建图。

2. Ninja 脚本中通过 rule 定义规则描述构建图中需要执行的动作。如：规则 cc 所定义的具体动作是 gcc -c $in -o $out，其中 $in 指代上游文件，$out 指代下游文件。对于 build test.o cc test.c 而言，最终执行的动作为：gcc -c test.c -o test.o。

3. 由 C 语言及其编译方式可知：当源文件包含的头文件改动时，源文件需要重新编译。因此，在构建图中头文件顺理成章的成为了源文件的上游文件，需要考虑的仅仅是如何定义 rule 最终触发编译动作。这里使用的技巧是通过命令 touh 更新源文件的修改时间，于是可定义 rule dp 的执行动作为 touch $out。这样 build test.c : dp test.h 的意思就很清楚了：当 test.h 被修改时，执行 touch test.c 更新修改时间，进而触发重新编译。

4. default test.out 指明默认构建的目标是 test.out，即：ninja 执行当前脚本时默认编译构建的是 test.out。

实验

理解了 Ninja 脚本的基本构成后就可以通过实验进一步体会了!

1. 将上面的脚本另存为文件，并重命名为 build.ninja，且与 test.c 和 test.h 位于同一目录下

2. 打开命令行定位到源码目录，执行 ninja > log.txt

通过编译输出 (log.txt) 以及 test.out 的运行结果可知目标构建成功。

后记：

这只是一个 Ninja 的入门级介绍，更多的细节大家可以参考附件中的手册。同时，文中的示例代码也可以在附件中下载。大家可以自己动手修改源码 (比如：修改 test.h 中 CONST 的值) 然后自行编译体会 Ninja 的用法。

Enjoy it!

©著作权归作者和 HarmonyOS 技术社区共同所有，如需转载，请注明出处，否则将追究法律责任。