背景
事情的起因是,想找个跨 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
自己下载的设置到 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 的大小完成了跨端支持,是很轻量的一个配置。如果您觉得实用并认可这种方式,欢迎一起来维护、完善。
posted on 2022-11-06 02:05
溪流 阅读(12877)
评论(0) 编辑 收藏 引用 所属分类:
C++ 、
Windows 、
Linux 、
Mac