前言
最近在搞libteec安全驱动的过程中，遇到了一个文件-BUILD.gn，心里想着这个是什么格式文件，真的五花八门
下面翻译了一篇谷歌的原文，大家可以一起学习一下，原英文版放在末尾了。
GN
1、什么是GN？
GN是一个生成Ninja Build文件的元构建系统。这意味着比GYP更快、更简单。它只输出Ninja构建文件。
2、为什么非要使用GN？
1、我们认为GN文件比GYP文件更可读、更易于维护。
2、GN速度快：
- GN比GYP快20倍（截至11月中旬，在运行Ubuntu Trusty的z620上，在一个配置而不是两个配置中，GYP构建的80%需要500毫秒。GYP需要20秒。我们在Mac和Windows上看到了类似的加速）。
- GN支持根据的需要Ninja 自动重新运行自己，作为构建的一部分。这样就不需要在更改构建文件时记住重新运行GN。
3、GN为我们提供了更好的工具来实施依赖关系（请参阅GN检查和可见性、public_deps和data_deps选项以了解一些示+ 例）。
4、GN为我们提供了查询构建图的工具；例如，你可以问“X依赖于什么”和“谁依赖于Y”。
3、现状？
截至2015年2月8日：
Chrome和大多数主要测试套件都链接到了Linux和ChromeOS上。在几个测试套件和一堆实用程序和助手二进制文件中，可能还剩下不到1000个对象需要构建。再过几周，我们可能会把一切都改好。
Chrome在Android和Windows上也有链接，剩下的测试套件应该很简单。在Windows上启用NaCl还有一些工作要做，但也应该很简单。
Mac和iOS进展不大，因为人们的注意力集中在Linux和Windows上；我们仍然需要对捆绑包和框架的支持，才能实现与其他平台的对等。
4、什么时候做完？
截至2015年2月8日：
我们目前正在争取在2015年3月底之前让主要的开发人员配置能够正常工作并可用。在接下来的几个月里，可能会对标志、错误修复等进行大量的验证，但我们希望在整个第二季度将配置从GYP转换为GN，目标是在第二季度末完成所有工作。
5、“完成”是什么意思？
理想情况下，当所有GYP文件都已从Chromium中删除并且没有人错过它们时，我们就完成了。
当以下情况属实时，我们将“大部分”完成：
- Chromeinfra团队为Chromium和Chromium下游维护的所有机器人都已切换到GN。（如Skia和V8等上游项目，如果愿意，可以选择继续使用GYP）。
- 我们关心的任何没有机器人的开发人员配置也可以工作（一般来说，我们的目标是没有这些。
- 我们关心的配置应该有机器人，以确保它们不会损坏）。我们已经验证了所有测试都通过了。
- 我们已经验证命令行在上述配置中尽可能匹配，我们接受任何差异。我们已经审查了导致正式版本的任何二进制差异，并接受了它们。GN文件是构建的“真相来源”，正常的铬开发人员通常不需要接触GYP文件来保持工作。我们有GYP目前可以构建的混合“msvs-ninja”和“xcode-ninja”配置的替代品。
“大部分已完成”和“已完成”之间的区别涵盖了我们尚未确定的任何问题：）
我们目前不计划支持GN的完全本机XCode或Visual Studio生成。理论上支持这样的功能是可能的，所以我们至少会看看添加了该功能的补丁。
构建系统
1 构建系统简介
在探讨chromium的最新GN构建系统之前，回顾一下软件开发中的构建系统。构建系统的需求是随着软件规模的增大而提出的。如果只是做软件编程训练，通常代码量比较小，编写的源代码只有几个文件。比如你编写了一段代码放入helloworld.c文件中，要编译这段代码，只需要执行以下命令：gcc helloworld.c
当软件规模逐渐增加，这时可能有几十个源代码文件，而且有了模块划分，有的要编译成静态库，有的要编译成动态库，最后链接成可执行代码，这时命令行方式就捉襟见肘，需要一个构建系统。常见的构建系统有GNU Make。需要注意的是，构建系统并不是取代gcc这样的工具链，而是定义编译规则，最终还是会调用工具链编译代码。
当软件规模进一步扩大，特别是有多平台支持需求的时候，编写GNU Makefile将是一件繁琐和乏味的事情，而且极容易出错。这时就出现了生成Makefile的工具，比如cmake、AutoMake等等，这种构建系统称作元构建系统（meta build system）。在Linux上软件仓库的概念还没有普及的时候，通常我们安装软件的步骤是：
- ./configure
- make
- make install
第一步就是调用AutoTool工具，根据系统环境（Linux的版本众多，软件安装情况也不一样），生成GNU Makefile。
2 Chromium中的构建系统
几年前的chromium开源项目采用的是GYP(Generate Your Projects）构建系统，这也是一种元构建系统。
软件工程师根据GYP规则编写构建工程文件（通常以gyp, gypi为后缀），GYP工具根据gyp文件生成GNU Makefile。接着chromium项目又整出了Ninja构建系统，但这个Ninja并不是用来取代GYP的，而是取代GNU make的，据谷歌官方的说法是速度有了好几倍的提升。
（ninja和make都是通过脚本语言指定编译规则，然后调用gcc等编译器实现自动化编译，过程中会通过文件时间戳来进行增量构建。）
（Ninja 舍弃了各种高级功能，语法和用法非常简单，给它指定好了具体详细要做什么，所以启动编译的速度非常快。根据 Chromium 的实际测试：在超过 30,000 个源文件的情况下，也能够在1秒钟内开始进行真正的构建。与之相比，通过资深工程师进行编写的 Makefiles 文件也需要10-20秒才能开始构建。但是ninja的功能可能不如makefile强大。）
（cmake是一个生成 .ninja 和 .makefile 的工具。因为担心很多人不熟悉makefile文件和ninja文件的写法，所以cmake只需要用户通过对源码文件的简单描述（就是CMakeLists.txt文件），就能自动生成一个project的makefile文件或者ninja文件，然后就可以通过ninja或者make进行启动编译了，很多IDE都在用cmake作为项目管理工具。）
对于我们开发者而言，不需要去深入了解Ninja或GNU Makefile这样构建系统，因为这只是一种中间输出，所以ninja的出现，与我们关系不大，原来怎么写gyp，现在还是怎么写，只是构建命令稍微做了改变。GN文件相当于gyp文件的下一代，和GYP差别不大，但是总体上比原来的GYP文件更清晰。
3 GN构建系统
GN是一种元构建系统，生成Ninja构建文件（Ninja build files），相较GYP而言，具有如下优点：
- 可读性更好，更容易编写和维护。
- 速度更快，谷歌官方给的数据是20倍的速度提升。
- 修改GN文件后，执行ninja构建时会自动更新Ninja构建文件。
- 更简单的模块依赖，提供了public_deps, data_deps等，在GYP中，只有一种目标依赖，导致依赖关系错综复杂，容易引入不必要的模块依赖。
- 提供了更好的工具查询模块依赖图谱。这在GYP构建系统中是一个噩梦，要查一个目标依赖哪些模块或者一个模块被哪些目标依赖几乎是不可能的。
- 更好的调试支持。在GN中，只需要一条print语句就可以解决。
参考链接
