Chrome GN 小结02

序

在CMake时代，它可以说来得早，但可惜的是，google内部有bazel/blade，并没有重视这个小而轻快的小工具。

基于python.exe 解释器的逻辑
从开源角度出发，开发者信任操作系统，信任python解释器，但不信任exe/dll插件。
于是gn选择了默认用python解释器当作plugin 对接其内部的action() {}
从而可以将plugin开源

Python友好吗?
它需要python环境和相应的第三方包(from pip)，也需要开发人员会写python。
再回过头看 Google Bazel需要携带Java友好吗？

如果你真的需要Chrome GN，请参见入门贴
https://blog.vrqq.org/archives/712/
以及目前的编译环境(从chromium source code精简而得)，欢迎大家多多补充third_party，充实这个repo。
TODO: GITHUB Repo Link here

作者注：我觉得自己很奇怪，可以理解C++语法思想和java，可以写NodeJS，但写不出Python。或许是从效率角度上无法感知Python做了什么，或许是担心写出来的脚本丑陋，奇怪的是，确实写不出。

注2：Facebook Buck 1代也给基于java，2代他们似乎明白了什么，改用Rust。我觉得Rust/Go更适合这种build-tools，而不是java。

GN的加载顺序

主要有三种target: executable，shared_library和static_library

解析顺序如下：

1. 根目录的.gn文件: buildconfig='//gn_build/BUILDCONFIG.gn'

2. 上述文件中提到的BUILDCONFIG.gn: set_defaults(), set_default_toolchain("//toolchain1:xxx")

   • set_defaults(): 设置target的默认参数
3. 每个文件下的BUILD.gn里面的 shared_library等等target

4. 第二步中提到的"//toolchain1:xxx" 针对每个arget 解析2、3两步累加的参数生成最终调用命令并运行

   • 注：target里面所有字段的生效顺序均为上述1->2->3，例如2中写了set_defaults() {config=[...]}，3里面就可以写shared_library() {config-=[...]}