Android build子系统（02）Ninja语法与复杂依赖构建解读

说明：本文将解读Ninja构建系统的基础语法和应用，同时给出一些示例便于理解和学习；给出一个复杂构建的基础demo，通过这个demo的分析理解复杂构建的内在逻辑和build.ninja编写法则；最后扩展之前Android Framework中构建build.ninja的2种新方式：android中的gradle方式和cmake方式。这样对Ninja这个构建系统有一个更具体的了解。

1 Ninja的基本语法解读

build.ninja 文件是 Ninja 构建系统的配置文件，它定义了如何构建项目中的各个目标（比如可执行文件、库文件等）。以下是 build.ninja 文件的一些基本语法规则和常见关键词的含义，以及一些示例。

1.1 基本语法规则解读如下：

• 规则（Rule）：定义了如何生成一个或多个文件的模板。
• 构建（Build）：定义了具体的构建指令，告诉 Ninja 如何生成一个目标。
• 变量（Variable）：用于简化构建文件，避免重复。

1.2 常见关键词解读如下：

• rule：定义一个构建规则。
• build：定义一个构建语句，指定输出文件和输入文件，以及使用哪个规则。
• variables：定义变量，可以在构建文件中重复使用。
• default：指定默认的构建目标。
• include：包含其他 .ninja 文件。
• subninja：包含另一个 .ninja 文件，通常用于子项目。

1.3 示例解读

接下来我们用示例的方式来看这些规则和关键词具体如何使用

1.3.1 规则定义示例如下:

# 定义一个名为 "cc" 的规则，用于编译 C++ 文件
rule cccommand = gcc -c $in -o $outdescription = Compiling $outrestat = 1 # 总是重新检查文件状态# 定义一个名为 "link" 的规则，用于链接生成可执行文件
rule linkcommand = gcc $in -o $outdescription = Linking $out

1.3.2 构建语句示例如下:

# 使用 "cc" 规则来编译 main.o 对象文件
build main.o: cc main.c# 使用 "link" 规则将 main.o 链接成可执行文件 "my_program"
build my_program: link main.o

1.3.3 变量定义参考示例如下：

# 定义变量
cxx = g++
flags = -Wall -O2# 使用变量
rule compilecommand = $(cxx) $(flags) -c $in -o $outdescription = Compiling $outbuild main.o: compile main.cpp

1.3.4 默认目标参考示例如下：

# 指定默认目标
default my_program

1.3.5 包含其他文件参考示例如下：

# 包含另一个 .ninja 文件
include foo.ninja# 包含变量文件
include variables.ninja

1.3.6 子项目参考示例如下：

# 包含子项目的 build.ninja 文件
subninja subproject.ninja

1.3.7 完整示例解读如下：

# 定义编译和链接规则
rule cccommand = gcc -c $in -o $outdescription = Compiling $outrule linkcommand = gcc $in -o $outdescription = Linking $out# 定义变量
cxx = g++
flags = -Wall -O2# 使用变量和规则来编译和链接
build main.o: cc main.c
build foo.o: cc foo.c# 链接生成可执行文件
build my_program: link main.o foo.o# 指定默认目标
default my_program

在这个示例中，我们定义了编译和链接的规则，然后使用这些规则来编译 main.c 和 foo.c 文件，并最终链接它们生成 my_program 可执行文件。我们还定义了一些变量来简化规则的命令，并指定了默认的构建目标。注意：在实际项目中，build.ninja 文件通常是由构建系统（如 CMake）生成的，而不是手动编写的。但理解其语法和结构对于自定义构建过程和调试构建问题非常有用。

2 Ninja复杂依赖体系的构建

2.1 一个复杂依赖体系构建的案例解读

这里假设 A依赖于B，B依赖于C的构建，B依赖于D的构建，C也依赖于D的构建，A B C D 均有自己的 build.ninja构建文件。那么想要依赖如何编写build.gradle呢？参考如下：

项目 A 的 build.ninja 文件 (build-A.ninja)：

build A: cc A.c B

项目 B 的 build.ninja 文件 (build-B.ninja)：

build B: cc B.c C D

项目 C 的 build.ninja 文件 (build-C.ninja)：

build C: cc C.c D

项目 D 的 build.ninja 文件 (build-D.ninja)：

build D: cc D.c

然后，在顶层的 build.ninja 文件中，使用 subninja 来包含这些子项目的构建文件，并定义最终的目标和依赖关系：

顶层 build.ninja 文件：

# 定义编译规则
rule cccommand = gcc -c $in -o $outdescription = Compiling $out# 包含子项目的构建文件
subninja build-A.ninja
subninja build-B.ninja
subninja build-C.ninja
subninja build-D.ninja# 定义最终的目标，这里假设 A 是最终目标
build A: phony B C
build B: phony C D
build C: phony D# 默认目标
default A

在这个顶层的 build.ninja 文件中，我们使用 subninja 来包含每个子项目的构建文件。然后，我们定义了最终的目标 A，并指定它依赖于 B 和 C。同样，B 依赖于 C 和 D，C 依赖于 D。这里使用了 phony 目标，因为 A、B 和 C 不是实际的文件，而是其他目标的别名。

请注意，这里的 cc 规则只是一个示例，你需要根据实际的编译命令来定义它。另外，每个子项目的 build.ninja 文件应该定义如何从源文件构建相应的目标。

要执行构建，只需在命令行中运行：

$ninja -f build.ninja

Ninja 会自动处理依赖关系，并确保在构建 A 之前先构建 B、C 和 D。

接下来我们针对复杂的编译构架体系，了解下 为什么很多大型项目中不直接编辑build.ninja，而是使用cmake、gn、soong、kati等其他工具来转换生成build.ninja。

2.2 为什么大型项目中不直接编辑build.ninja？

在实际项目中，build.ninja 文件通常不是直接编辑的，而是通过其他构建系统生成的，主要有以下几个原因：

1. 复杂性管理： 大型项目可能有成百上千的源文件和复杂的依赖关系。手动编辑 build.ninja 文件来管理这些复杂性是非常困难且容易出错的。

2. 可维护性： 如果 build.ninja 文件是手动编写的，那么每次项目结构或依赖关系发生变化时，都需要手动更新这个文件，这很难保持一致性和准确性。

3. 自动化： 使用自动化的构建系统（如 CMake、Meson 或 Bazel）可以自动分析项目的源代码和依赖关系，并生成相应的 build.ninja 文件。这样可以确保构建文件始终是最新的，并且与项目的实际结构保持同步。

4. 跨平台支持： 自动化构建系统可以生成跨多个平台的构建文件。例如，CMake 可以生成 Windows、Linux 和 macOS 都能使用的 Ninja 文件，而手动编写则需要为每个平台单独编写和维护构建文件。

5. 可读性和可理解性： 构建系统（如 CMake）使用的配置文件（如 CMakeLists.txt）通常更易于理解和维护。开发者可以专注于用这些高级构建脚本来定义构建逻辑，而不是直接处理底层的构建文件。

6. 复用性和一致性： 在大型组织或多个项目中，使用统一的构建系统可以确保所有的项目都遵循相同的构建流程和标准，这有助于保持构建过程的一致性。

7. 高级功能： 现代构建系统提供了许多高级功能，如预编译头文件、依赖扫描、自动生成项目文件等，这些功能很难通过手动编辑 build.ninja 文件来实现。

8. 社区和生态系统： 构建系统如 CMake 拥有庞大的社区和丰富的文档，开发者可以轻松找到帮助和资源。而直接编辑 build.ninja 文件则意味着离开了这个生态系统，减少了可获得的支持。

尽管 build.ninja 文件不是直接编辑的，但理解其内容和结构对于调试构建问题和定制构建过程是非常有帮助的。构建系统提供了一个抽象层，允许开发者以更高级、更易于管理的方式定义构建逻辑，而自动生成 build.ninja 文件则确保了构建过程的准确性和高效性。

3 gradle和cmake使用Ninja构建

3.1 gradle中Ninja编译的构建

说明：从 Android Gradle Plugin (AGP) 3.0 开始，Ninja 被设置为默认的构建系统来编译原生代码，替代了之前的 make 工具。如果你的项目中包含 C 或 C++ 代码，AGP 会自动使用 Ninja 进行构建，即使你没有显式地在 build.gradle 文件中指定使用 Ninja。

这个变化是为了提高构建性能，因为 Ninja 通常比 make 更快，尤其是在处理大型项目或频繁构建时。Ninja 的并行构建能力可以显著减少构建时间。如果你的gradle版本默认不是ninja，则参考如下步骤，配置使用ninja编译的方式如下：

第一步，全局配置。在项目的根目录下的gradle.properties文件中设置以下属性，这将影响所有的项目和模块。

android.useAndroidX=true
android.enableJetifier=true
org.gradle.parallel=true
# 设置Ninja为默认构建工具
org.gradle.native.cpp.build.type=Ninja

第二步，在模块的build.gradle文件中，确保你已经应用了com.android.application或com.android.library插件，并配置了externalNativeBuild以使用Ninja。配置如下所示：

apply plugin: 'com.android.application' // 或 'com.android.library'android {// ...buildTypes {release {// ...externalNativeBuild {cmake {arguments "-GNinja", "-DCMAKE_BUILD_TYPE=Release"}}}debug {// ...externalNativeBuild {cmake {arguments "-GNinja", "-DCMAKE_BUILD_TYPE=Debug"}}}}
}

3.2 cmake中ninja编译的构建

这里用 CMake 将 CMakeLists.txt 文件转换成 build.ninja 文件，你需要在命令行中运行 CMake 并指定 Ninja 作为生成的构建系统。下面是一个简单的示例，展示了整个过程：

@1 创建 CMakeLists.txt

首先，创建一个包含基本构建指令的 CMakeLists.txt 文件。例如，如果你有一个简单的 C 程序，包含两个源文件 main.c 和 hello.c，并且你想将它们编译成一个可执行文件 hello，你的 CMakeLists.txt 可能如下所示：

# CMakeLists.txt
cmake_minimum_required(VERSION 3.0)# 定义项目名称和语言
project(MyProject C)# 定义要构建的可执行文件及其源文件
add_executable(hello main.c hello.c)

@2 运行 CMake 命令

然后，在命令行中运行 CMake 命令，指定 Ninja 作为构建系统，并生成构建文件。你需要确保已经安装了 CMake 和 Ninja，并且 Ninja 的可执行文件在系统的 PATH 环境变量中。

$cmake -G Ninja -DCMAKE_BUILD_TYPE=Release .

这个命令告诉 CMake 使用 Ninja 生成构建文件，并设置构建类型为 Release。-G Ninja 参数指定了生成器为 Ninja，-DCMAKE_BUILD_TYPE=Release 设置了构建类型，. 表示当前目录是源代码的根目录。

运行上述 CMake 命令后，CMake 会在当前目录下生成一个 build.ninja 文件，以及一个 CMakeFiles 目录，其中包含了一些中间文件。这时可以打开 build.ninja 文件查看其内容。它将定义如何使用 Ninja 构建你的项目。例如，它可能包含如下内容：

# Auto-generated by CMake - do not edit!rule CMAKE_RULEcommand = /usr/bin/cmake -E make_directory $outdescription = Creating directory: $outrule compilecommand = /usr/bin/gcc -fPIC -o $out -c $indescription = Compiling $outrule linkcommand = /usr/bin/gcc -o $out $indescription = Linking $outbuild CMakeFiles/hello.dir/main.c.o: compile CMakeFiles/hello.dir/main.c
build CMakeFiles/hello.dir/hello.c.o: compile CMakeFiles/hello.dir/hello.c
build hello: link CMakeFiles/hello.dir/main.c.o CMakeFiles/hello.dir/hello.c.o

@3 使用Ninja 构建项目

有了build.ninja文件，就可以使用 Ninja 来构建项目：

$ninja -f build.ninja

这个命令将根据 build.ninja 文件中的指令来编译和链接你的项目，生成最终的可执行文件 hello。

通过上述步骤，可以使用 CMake 将 CMakeLists.txt 转换成 build.ninja 文件，并使用 Ninja 进行构建。这种方法非常适合需要精确控制构建过程和依赖关系的复杂项目。