[openharmony]liteos-a系统编译之GN

在 文章 中已经分析openharmony的小型系统（liteos-a）编译过程，最主要的就是调用gn/ninja/makefs三个命令最终生成可烧录的镜像文件

从前面文件可以看到hb build调用的gn命令参数如下

这里详细分析一下gn工具在编译过程中的使用

这里简单介绍谨拍下GN工具的使用方法，gn语法可以参考 http://weharmonyos.com/openharmony/compile/gn/docs/

，已经熟悉的可以跳过

从上面图中可以看到使用的命令类型为 gn gen <output_dir>[options] ，此命令裤行就是为了将所有需要的BUILD.gn文件生成为*.ninja文件供ninja进行编译可以通过 gn help gen 命令查看详细的用法说明， 如下

下面重点说一下gn_cmd中的 [options]

liteos-a编译系统的dotfile内容如下:

liteos-a是嵌入式系统，而编译环境是linux系统，这就需要用到交叉编译方式，这个就可以在环境配置中指定 target_os 、 target_cpu 、 board_cpu 等等信息

这些信息就是 buildconfig 参数指定的 BUILDCONFIG.gn 文件中胡晌哗配置的

除了以上信息，还配置了以下几个重要信息

详细信息可以查看 //build/lite/config/BUILDCONFIG.gn 文件内容

toolchain定义源码编译需要的工具，像编译器、汇编器、连接器等等，一般在.gn所在目录下有一个 toolchain 目录，里面的 BUILD.gn 定义详细的编译工具链信息

这里目录结构如下：

从结构信息中可以看到定义了clang和gcc两种工具链，通过变量 board_toolchain_type 来区分（此变量也是buildconfig中定义的），具体信息参见BUILD.gn文件内容，如下

在.gn文件所在目录下的BUILD.gn就是入口，此文件做了以下几个事情

这里重点说一下target为 ohos 的 group 如下：

这里也比较好理解，里面就是读取一个配置文件，几级循环来处理配置文件中配置的内容。流程如下

到此就将此board下各模块的依赖关系添加好了，然后 GN 会将依赖树中所有的BUILD.gn生成对应的.ninja文件，并且在out的根目录下生成下面几个ninja的入口文件以及配置文件

运行 gn ，你只需从命令行运行 gn ，对于大型项目，GN是与源码一起的。

与其他一些构建系统不同，在GN中你可以设置你自己的构建目录，和你想要的设置。这让你可以根据需要维护不同的构建，可以根据自己的需要并行维灶圆护不同的构建。

一旦你生成了一个构建目录， ninja 文件将被自动生成，如果你在该目录下进行构建时，文件已经过期， ninja 则会自动重新生成，所以你不必重新运行 gn 。

建立一个构建目录：

在你的构建目录上运行设置构建参数：

这将d出一个编辑器，在该文件中输入build args，像这样：

可用的变量将取决于你的构建，你可以看到可用参数的列表和它们的默认值。

通过键入:

可以看到可用的参数列表和默认值，这个命令必须指定编译目录，因为不同的目录有不同的参数值。

Chrome的开发者也可以阅读 Chrome特有的构建配置 说明以了解更多信息。

运行 gn args out/Default （根据需要替换成你的构建目录），然后为常见的交叉编译选项添加以下一行或多行:

更多信息请参见 GN cross compiles 。

转到 examples/simple_build 目录，这档此是一个最小的GN仓库的root目录。

在该目录中，有一个 tutorial 目录。这里已经有一个 tutorial.cc 文件，但没有与构建挂钩。在该目录中为我们的新目标创建一个新的 BUILD.gn 文件，用于我们的新目标:

现在我们只需要告诉编译器这个新的目标。

打开目录（ simple_build ）下的 BUILD.gn 文件，GN从加载这个根文件，然后从这里开始加载所有的依赖项，所以我们只需要在这里添加对这个文件中的新目标的引用。

你可以把我们的新目标作为一个依赖关系加入到现有的目标中去，但把一个可执行文件作为依赖关系并没有什么意义。通常情况下，将一个可执行文件作为另一个可执行文件的依赖项是没有意义的（它们不能被链接）。

所以让我们做一个 tools group 组。在GN中，一个 group 只是一个依赖关系的集合，没有编译或链接:

从 simple_build 目录下的命令行:

执行 ./out/tutorial

你应该看到 Hello from the tutorial. 输出到控制台。

题外话： GN 鼓励静态库的目标名称不是全局唯一的。要建立一个这样的库，你可以把标签和它的路径（但没有前面的 // ）给 ninja ：

所以前面的tutorial可以是：

让我们看看在下列文件 examples/simple_build/BUILD.gn 中定义的目标。这里有一个静态库定义了一个函数， GetStaticText() ：

还有一个共享库，定义了一个函数 GetSharedText() ：

这也说明了如何为隐蠢塌一个目标设置预处理程序的定义，要设置多个以上的定义或赋值，请使用这种形式：

现在我们来看看依赖这两个库的可执行文件：

这个可执行文件包括一个源文件，并依赖于前面的两个库，以冒号开头的标签指的是当前BUILD.gn文件中具有该名称的目标。

在 simple_build 目录下的命令行中:

注意，你 不需要 重新运行GN。当任何构建文件发生变化时，GN会自动重新构建

ninja文件。因为ninja在开始执行时打印出 [1/1] Regenerating ninja files 时，你就知道这个发生了。

一个库的用户经常需要用到 compile flags 、 defines 、 include directories ，要做到这一点，把所有这些设置放到一个 "config "中就可以，这是一个命名的设置集合（但不包括源和依赖关系）。

要将一个配置的设置应用于目标，请将其添加到 configs 列表中。

一个配置可以应用于所有依赖当前配置的目标，只要把它的标签放在 public_configs 列表中。

public_configs 也适用于当前的目标，所以不需要在两个地方都列出一个配置。

构建配置将设置一些默认适用于每个 target 的设置。

默认情况下，这些通常会被设置为默认的配置列表。你可以用 print 命令看到 你可以使用 print 命令看到这一点，这对调试很有用:

运行GN将打印类似的东西:

目标可以修改这个列表以改变其默认值。

例如，构建设置可能会通过添加 no_exceptions 配置来默认关闭异常，但目标可以通过用不同的配置来重新启用它们:

我们上面的打印命令也可以用字符串插值来表达，这是一种将数值转换成字符串的方法。它使用符号"$"来指代一个变量。

执行 ninja -C out hello

你可以通过 declare_args 声明你接受哪些参数并指定默认值。

参见 gn help buildargs 以了解其工作原理。

参见 gn help declare_args 以了解声明参数的具体细节。

在一个给定的范围内多次声明一个参数是一个错误，所以在确定参数的范围和命名时应该谨慎。

你可以在verbose模式下运行GN，以看到很多详细过程，使用 -v 参数就可以：

你可以运行 gn desc <build_dir><targetname>来获取有关

一个给定的目标。

获取 ldflags 信息

假设你想知道你的 TWO_PEOPLE 定义来自哪里:

另一个特别有趣的变体:

更多信息见 gn help desc 。

所有可以参与依赖关系的图（目标、配置和工具链）都由标签来识别，一个常见的标签看起来像：

这个例子包括一个source-root绝对路径、一个冒号和一个target，这意味着要在 "base/test/BUILD.gn "中寻找名为 "test_support "的目标。 如果有必要，你也可以指定系统的绝对路径。通常情况下，这样的路径会通过构建参数来指定，所以开发者可以指定组件在他们系统中的位置。

一个规范的标签包括正在使用的工具链的标签。通常情况下，工具链标签隐含地继承自当前的执行环境，但你可以覆盖它以指定跨工具链的依赖关系。

这里 GN 将在文件"//build/toolchain/win "中寻找名为 "msvc "的工具链定义，以知道如何编译这个目标。

如果你想引用同一构建文件中的东西，你可以省略路径名称，只用冒号开头。这种格式被推荐用于同文件中的标签引用。

标签可以被指定为相对于当前目录的标签。从风格上看，我们更倾向于对所有非文件本地的引用使用绝对路径，除非一个构建文件需要在不同的环境下运行（比如一个项目既需要独立运行，又需要拉到目录层次中不同位置的其他项目中）。

如果一个名字没有被指定，它将继承目录名称。从风格上看，我们倾向于在可能的情况下省略冒号和名称。

CMake是一个比make更高级的编译配置工具，它可以根据不同平台、不同的编译器，生成相应的Makefile或者vcproj项目。

通过编写CMakeLists.txt，可以控制生成的Makefile，从而控制编译过程。CMake自动生成的Makefile不仅可以通过make命令构建项目生成目标文件，还支持安装（make install）、测试安装的程序是否能正确执行（make test，或者ctest）、生成当前平台的安装包（make package）、生成源码包（make package_source）、产生Dashboard显示数据并上传等高级功能，只要在CMakeLists.txt中简单配置，就可以完成很多复杂的功能，包括写测试用例。

如果有嵌套目录，子目录下可以有自己的CMakeLists.txt。

总之，CMake是一个非常强大的编译自动配置工具，支持各种平台，KDE也是用它编译的，感兴趣的可以试用一下。

用法：

1、安装CMake

2、cmd或powershell下键入 cmake查看，是否安装已加入到环境变量路径，若否，需手动设置

3、cd 到工程目录下有CMakeLists.txt的目录下

4、cmake . 开始构建vs解决方案，生成 xxx.sln

5、vs打开即可

GYP （Generate Your Projects）是由 Chromium 团队开发的跨平台自动化项目构建拆中工具，Chromium 便是通过 GYP 进行项目构建管理。为什么要选择 GYP，而放弃 CMake 呢？功能上 GYP 和 CMake 很是相似，在我看来，它们的最大区别在于配置文件的编写方式和其中蕴含的思想。

编写 CMake 配置文件相比 Autotools 来说银御乱已经简化很多，一个最简单的配置文件只需要写上源文件及生成类型（可锋档执行文件、静态库、动态库等）即可。对分支语句和循环语句的支持也使得 CMake 更加灵活。但是，CMake 最大的问题也是在这个配置文件，编写 CMake 配置文件是一种线性思维，对于同一个目标的配置可能会零散分布在各个地方。而 GYP 则相当不同，GYP 的配置文件更多地强调模块化、结构化。

所以说GYP代替CMake也是有其原因的。

GN比GYP速度快20倍，而且简单，所以谷歌就把GYP标注为过期，相关项目都迁到GN上来

---