建立一个简单干净的 gn+ninja 工具链

标签：toolchain output 干净 build gn ninja 工具

背景

事情的起因是，想找个跨 Windows 和 Mac 的构建方案。第一考虑自然是 CMake，毕竟基本上是事实标准了。

但是研究了一下 Modern CMake，也就是以 target 为核心的理念。但发现看了好几天文档，也折腾出了可用的东西，但仍然是没梳理清楚什么理念、原理。然后 CMake 本身语法就很复杂，再加上搞 target 一套概念，要给 target 设置各种属性之类的，有点强行 OOP 的感觉……但其实我们只是需要一个 include_dir 和 lib_dir 而已，其他都是浮云~

但如果退回到传统模式，不用 Modern 概念呢，好像可以将就，但第一不去用一个工具的最新模式，好像有点不上进的感觉（python 2 除外）；第二，CMake 的两大痛点——语法特立独行、文档晦涩难懂——还是让人有点不爽。

那跳出来看别的选择呢？目前相对成熟的也只有 Google 的 gn+ninja 方案了。gn 这套东西在 Chromium 里是完全配置好的，用起来还算顺手，但要是独立拿出来呢，就没那么便宜了。关键是它的 toolchain 是要自己定义的。

之前还在公司搞客户端的时候，大家就从 Chromium 里面把 build、build_overrides 等等东西全部拷出来，好家伙，几百 MB 甚至上 G。但是公司里嘛，没人管干不干净，怎么快怎么来。后来又看到 Google 自家的 Crashpad 里面也用了这套构建，但工具链被简化了一下，叫 mini_chromium。这个比 Chromium 里的小多了，是可以拿过来直接用的，缺少一些配置可以自己加。但是呢，像我们这种洁癖，仍然是受不鸟的。所以呢，我们要干干净净的建立一套工具链。

构建系统安装

首先，我们明确定位。gn 和 ninja 都是开发机上需要预装的，不是软件提供的。Chromium 的搞法是自己提供，gn 的文档也说让开发者提供工具。但这套思路跟传统的理念是冲突的。同时，自己安装工具成本是比较低的：

• linux
  • ninja 在主流包管理系统里已经有了，包名可能是 ninja 或 ninja-build，直接安装就可以
  • gn 在部分包管理系统有，尝试包名 gn 或 gn-build 等，没有的话可以下载二进制版本，或者从源代码自行编译
• mac
  • ninja 在 brew 里包名叫 ninja，在 MacPorts 里包名叫 ninja-build
  • gn 在 brew 里没有，可以下载二进制版本；在 MacPorts 里叫 gn-devel
• win
  • ninja 可以在 GitHub 下载二进制版本，gn 可以在 gn 官网下载二进制版本

自己下载的设置到 PATH，测试 gn --version 以及 ninja --version，能运行即可

目标

希望做到提供一个 git repo，使用者 clone 到自己项目的 build 目录，然后使用者只要在 .gn 文件里配置

buildconfig = "//build/BUILDCONFIG.gn"

就可以使用我们提供的工具链，在 PC 三端进行构建。

使用者的唯一负担就是编写自己的 BUILD.gn

工具链搭建

首先我们看 gn 的文档，以及它的例程 simple_build 里的工具链配置：

https://gn.googlesource.com/gn/+/HEAD/examples/simple_build/build/toolchain/BUILD.gn

这个是可以直接用的，只不过只有 linux 端（当然 mac 也能用）。我们再结合 chrome 里的工具链配置，进行一些完善。

基础概念

首先我们了解 gn 体系需要的最小配置是什么。

第一，它需要在根目录写一个 .gn 文件，在里面定义 buildconfig，指到另一个文件，一般是

buildconfig = "//build/BUILDCONFIG.gn"

第二、BUILDCONFIG.gn 里面需要设置默认工具链，也就是写一行

set_default_toolchain("//build/toolchain:gcc")

第三、定义工具链，如上例的 //build/toolchain:gcc。

需要在 build/toolchain 下建立 BUILD.gn 文件，内容是

toolchain("gcc") {
	# ...
}

最后在 toolchain 里定义各种 tool。

工具链中的工具

这部分文档在这里：https://gn.googlesource.com/gn/+/main/docs/reference.md#func_tool

简单复述一下，可被定义的工具有：

• 编译工具:
  "cc": C 编译器
  "cxx": C++ 编译器
  "cxx_module": 支持 module 的 C++ 编译器
  "objc": Objective C 编译器
  "objcxx": Objective C++ 编译器
  "rc": Windows 资源脚本编译器
  "asm": 汇编器
  "swift": Swift 编译器
• 链接工具:
  "alink": 静态库链接器
  "solink": 动态库链接器
  "link": 可执行文件链接器

（其他的就先不看了）

我们来看一下 https://gn.googlesource.com/gn/+/HEAD/examples/simple_build/build/toolchain/BUILD.gn 的一些关键配置：

toolchain("gcc") {
  tool("cc") {
    command = "gcc -MMD -MF $depfile {{defines}} {{include_dirs}} {{cflags}} {{cflags_c}} -c {{source}} -o {{output}}"
    outputs = [ "{{source_out_dir}}/{{target_output_name}}.{{source_name_part}}.o" ]
    # ...
  }
  tool("cxx") {
    command = "g++ -MMD -MF $depfile {{defines}} {{include_dirs}} {{cflags}} {{cflags_cc}} -c {{source}} -o {{output}}"
    outputs = [ "{{source_out_dir}}/{{target_output_name}}.{{source_name_part}}.o" ]
    # ...
  }
  tool("alink") {
    command = "rm -f {{output}} && ar rcs {{output}} {{inputs}}"
    outputs = [ "{{target_out_dir}}/{{target_output_name}}{{output_extension}}" ]
    # ...
  }
  tool("solink") {
    command = "g++ -shared {{ldflags}} -o $sofile $os_specific_option @$rspfile"
    outputs = [ sofile ]
    # ...
  }
  tool("link") {
    command = "g++ {{ldflags}} -o $outfile -Wl,--start-group @$rspfile {{solibs}} -Wl,--end-group {{libs}}"
    outputs = [ outfile ]
    # ...
  }
  tool("stamp") {
    command = "touch {{output}}"
  }
  tool("copy") {
    command = "cp -af {{source}} {{output}}"
  }
}

可以看到，cc 和 cxx 执行 command 后，生成 .o 文件，然后这些 .o 文件可以作为 alink、solink、link 的 inputs，被它们 command 继续使用，最后输出静态库、动态库以及可执行文件。

其余属性可以查文档了解含义。

对比 Chromium 中的配置

Linux

主要配置在这里：https://source.chromium.org/chromium/chromium/src/+/main:build/toolchain/gcc_toolchain.gni

也是 gcc 的，与 simple_build 里的大同小异，没有特别的。

Mac

主要配置在这里：https://source.chromium.org/chromium/chromium/src/+/main:build/toolchain/apple/toolchain.gni

区别有：

• 用 clang 系列编译工具，而不是 gcc
• alink 不是用 ar，而使用 libtool
• solink 的默认扩展名改成了 dylib
• 用了一个 linker_driver.py 来支持生成 dSYM，在里面调用了 dsymutil 和 strip

Win

• 编译用 cl，静态库链接用 lib，动态库和可执行文件的链接用 link
• lib_switch = ""，lib_dir_switch = "/LIBPATH:"；前两者 lib_switch = "-l"，lib_dir_switch = "-L"

建立我们的工具链

基本上是根据上面分析的要点配置，最终结果在此：https://github.com/Streamlet/gn_toolchain

新增的一些差异有：

• 增加全局参数 is_debug，可以在 gn gen out --args="is_debug=true"传入。默认 is_debug 为 false，开启所有优化。

• mac 下生成 dSYM 不使用 python 脚本，直接是 $ld ... && dsymutil ... && strip

• mac 下加了一个 template：app_bundle，用来生成 xxx.app，主要配置来自于 create_bundle 文档里的例子

• win 下增加了一些配置集

  • 动态/静态链接 CRT：//build/config/win:console_subsystem、//build/config/win:static_runtime

  • 控制台程序、Win32 程序：//build/config/win:console_subsystem、//build/config/win:windows_subsystem

    这个其实一般情况下用不着，只要入口函数是 main/WinMain，link 默认就是控制台程序/Win32 程序

  • XP 支持：//build/config/win:console_subsystem_xp、//build/config/win:windows_subsystem_xp

    具体实现是链接参数加 /SUBSYSTEM:CONSOLE,5.01 或 /SUBSYSTEM:WINDOWS,5.01。关键是后面的版本号 5.01，为了加版本号则必须指定子系统名称，所以分了 console_subsystem_xp 和 windows_subsystem_xp。又，xp 这里提供了两个 subsystem 的配置集，非 xp 也提供两个。

    但是我们没有加 _WIN32_WINNT=0x0501、WINVER=0x0501、_USING_V110_SDK71_，也没有指定必须使用 7.0 版本的 SDK，这些都是非必须的，只要不用到 XP 以后添加的 API 即可。使用者可以在自己的 target 里面定义这些宏。

使用案例

提供一个使用案例：https://github.com/Streamlet/gn_toolchain_sample

因为它以 git submodule 形式引用了 https://github.com/Streamlet/gn_toolchain，所以 git clone 以后，需要 git submodule update --init一下。

然后在根目录执行：（确保 gn 和 ninja 已经在 PATH 中）

gn gen out
ninja -C out

即可。

Mac 下会额外生成一个 objc 项目 objc_console_application 以及一个 app_bundle：ns_application.app。

Win 会额外生成一个 Win32 项目 win32_application。

Win 下需要先执行一下 Visual Studio 带的命令行环境，如 VS 2022 Community 的 “x64 Native Tools Command Prompt for VS 2022”，cl 等工具才会可用。

如果要测试 XP（32位），用“x86 Native Tools Command Prompt for VS 2022”进入，CD 到项目目录，执行：

gn gen out --args="target_cpu=\"x86\""
ninja -C out

总结

我们只用几十 KB 的大小完成了跨端支持，是很轻量的一个配置。如果您觉得实用并认可这种方式，欢迎一起来维护、完善。

标签：toolchain,output,干净,build,gn,ninja,工具
From： https://www.cnblogs.com/Streamlet/p/16975019.html