miniblink49 仓库内 Google Test 构建指南从源码编译、CMake 集成到宏调优的完整实践【免费下载链接】miniblink49a lighter, faster browser kernel of blink to integrate HTML UI in your app. 一个小巧、轻量的浏览器内核用来取代wke和libcef项目地址: https://gitcode.com/GitHub_Trending/mi/miniblink49导读本指南以 v8_5_7/testing/gtest/README.md 为核心骨架系统讲解如何将 Google C Testing FrameworkGoogle Test集成进大型 C 项目。miniblink49 是一个以 Chromium/Blink 为基底、用于在应用中嵌入 HTML UI 的轻量浏览器内核其 v8_5_7 测试工具链中完整保留了 Google Test 源码树头文件、实现、样例、构建脚本一应俱全。读完本文你将掌握在 Linux/Windows/macOS 上从零编译 gtest 静态库与动态库、用 CMake 生成跨平台构建工程、构建官方样例与 gtest 自测、以及通过一组GTEST_*编译宏按需裁剪tuple 选择、线程支持、宏名冲突规避等的完整实战方案。仓库中的 Google Test 源码布局在动手编译前先认清 miniblink49 仓库中 Google Test 的目录结构以下路径均相对仓库根目录v8_5_7/testing/gtest/include全部公共头文件核心是 gtest/gtest.h以及内部实现头 gtest/internal/gtest-port.h、gtest-internal.h 等v8_5_7/testing/gtest/src全部实现源文件包括聚合编译入口 gtest-all.cc、提供main()的 gtest_main.cc、死亡测试 gtest-death-test.cc 等v8_5_7/testing/gtest/samples官方示例sample1_unittest等v8_5_7/testing/gtest/make/MakefileGNU make 构建脚本v8_5_7/testing/gtest/CMakeLists.txtCMake 跨平台构建脚本msvc/、xcode/、codegear/面向 Visual Studio、Xcode、CodeGear 的传统工程README 明确标注为 Legacy遗留脚本仅作便利保留。本文所有命令中的${GTEST_DIR}均指 v8_5_7/testing/gtest请按你解压或检出到的实际路径替换。通用构建流程手动集成第一步编译 gtest 库本体README 推荐的核心做法是只编译一个源文件src/gtest-all.cc。从该文件源码可以看到它通过#include依次拉入gtest.cc、gtest-death-test.cc、gtest-filepath.cc、gtest-port.cc、gtest-printers.cc、gtest-test-part.cc、gtest-typed-test.cc全部实现因此单文件编译即可得到完整测试框架。编译时有两处头文件搜索路径要求将${GTEST_DIR}/include放入系统头文件搜索路径-isystem避免编译器对 gtest 头产生告警将${GTEST_DIR}放入普通头文件搜索路径-I使src/gtest-all.cc内的相对包含#include src/gtest.cc可被解析。在 Linux 类系统 gcc 环境下g -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \ -pthread -c ${GTEST_DIR}/src/gtest-all.cc ar -rv libgtest.a gtest-all.o必须加-pthreadREADME 明确指出 We need-pthreadas Google Test uses threads。第二步编译并链接你的测试编写测试源文件your_test.cc后编译时仍将${GTEST_DIR}/include作为系统头路径链接 gtest 静态库与其他必要库g -isystem ${GTEST_DIR}/include -pthread path/to/your_test.cc libgtest.a \ -o your_test这里链接的是不含main()的libgtest.a因此你的测试文件需自行提供main()。若希望使用框架自带的main()可改用 src/gtest_main.cc 编译出的gtest_main.a进行链接。借助官方 Makefile 快速上手make/Makefile 是 README 提到的现成起点它不构建 gtest 自身测试只产出 gtest 库与一个样例测试。该 Makefile 的关键变量与规则值得逐行研读GTEST_DIR ..指向 gtest 根目录相对 Makefile 位置移动到你的工程时需调整USER_DIR ../samples用户代码目录指向官方样例CPPFLAGS -isystem $(GTEST_DIR)/include把 gtest 头设为系统目录抑制其内部告警CXXFLAGS -g -Wall -Wextra -pthread调试信息、完整告警、线程支持目标gtest.a由gtest-all.o归档而成gtest_main.a额外加入gtest_main.o目标sample1_unittest链接gtest_main.a样例未自定义main()。在默认环境配置正确的前提下README 给出的三步即可直接验证cd ${GTEST_DIR}/make make ./sample1_unittest若报错则根据报错微调make/Makefile中的编译/链接选项例如针对非 Linux 平台的 pthread 标志差异Makefile 内有详细注释说明。使用 CMake 跨平台构建基本构建流程CMake 的价值在于一次编写、多平台生成原生构建工程。标准工作流mkdir mybuild # 创建构建输出目录 cd mybuild cmake ${GTEST_DIR} # 生成原生构建脚本在 *nix 上会生成Makefile直接执行make即可构建 gtest在 Windows 上安装了 Visual Studio会生成gtest.sln与多个.vcproj工程文件可在 VS 中构建在 macOS安装了 Xcode会生成.xcodeproj工程。构建官方样例若需要同时构建 gtest 的 sample 程序将 cmake 命令替换为cmake -Dgtest_build_samplesON ${GTEST_DIR}该开关与 CMakeLists.txt 中的option(gtest_build_samples Build gtests sample programs. OFF)一一对应默认 OFF。构建 gtest 自身测试开发 gtest 时修改 gtest 源码后建议编译并跑通 gtest 自带的测试套件mkdir mybuild cd mybuild cmake -Dgtest_build_testsON ${GTEST_DIR}注意部分 gtest 自测由 Python 编写机器上必须装有 Python。若 cmake 报Could NOT find PythonInterp (missing: PYTHON_EXECUTABLE)需显式指定解释器路径cmake -DPYTHON_EXECUTABLEpath/to/python -Dgtest_build_testsON ${GTEST_DIR}*nix 下构建用make运行测试用make test正常情况下全部通过。该开关对应 CMakeLists 的option(gtest_build_tests Build all of gtests own tests. OFF)。CMake 提供的其他开关从 CMakeLists.txt 可看到更多可调项默认值以源码为准BUILD_SHARED_LIBS默认 OFF是否将 gtest 构建为共享库Windows 上即 DLLgtest_disable_pthreads默认 OFF是否禁用 gtest 对 pthread 的使用对应下面将要介绍的GTEST_HAS_PTHREAD0。遗留构建脚本Legacy Build Scripts在采用 CMake 之前gtest 长期提供手写维护的 Visual Studio、Xcode、Autotools 工程。README 明确提示这些脚本不再积极维护仅作便利保留强烈建议优先采用前述通用编译或 CMake 方案。如需使用要点如下Visual Studio打开msvc/目录下的gtest.sln或gtest-md.sln。命名后缀-md表示使用 Microsoft 运行时库的 DLL 版本/MD或/MDd不带后缀的表示静态运行时/MT或/MTd。必须保证编译 gtest 与编译你的测试代码使用相同的运行时选项否则会出现运行时库冲突。若使用 VS2005 及以上版本官方推荐-md版本因为/MD是这些版本新工程的默认值macOS / Xcode用 Xcode 打开xcode/下的gtest.xcodeproj构建 gtest target通用二进制框架会输出到构建目录默认xcode/build。也可在命令行执行xcodebuild该命令会构建默认位置下的gtest.frameworkRelease 配置。若使用 Xcode 4.x 及以上需二选一修改xcode/Config/General.xconfig注释掉SDKROOT、MACOS_DEPLOYMENT_TARGET、GCC_VERSION三个选项代价是无法再针对更早的 macOS 版本安装早期版本的 SDK。按需调优一组 GTEST_* 控制宏Google Test 面向多种环境默认配置在某些平台上可能不理想可通过在编译命令行定义形如GTEST_XYZ的宏赋值为 1 或 0 启用/禁用特性进行调优。这些宏的权威完整清单见 include/gtest/internal/gtest-port.h如GTEST_HAS_EXCEPTIONS、GTEST_HAS_RTTI、GTEST_HAS_POSIX_RE、GTEST_HAS_SEH、GTEST_LANG_CXX11等。注意该头文件约定用户未定义的宏会被自动补默认值且统一用#if而非#ifdef判定参见文件头部注释因此这类宏在#include后总是处于已定义状态。选择 TR1 tuple 库部分 gtest 特性依赖 C TR1 的 tuple 库而并非所有编译器都自带。好消息是 gtest 内置了一份够用的 TR1 tuple 子集实现gtest-tuple.h编译器缺少 TR1 tuple 时会自动启用。通常无需关心选用哪个 tuple 实现但若你的项目已在使用 TR1 tuple则必须让 gtest 与项目保持一致否则两套 tuple 实现会冲突-DGTEST_USE_OWN_TR1_TUPLE0 # 使用项目已有的 TR1 tuple -DGTEST_USE_OWN_TR1_TUPLE1 # 强制使用 gtest 内置 tuple -DGTEST_HAS_TR1_TUPLE0 # 完全禁用 tuple所有依赖 tuple 的特性关闭从 gtest-port.h 的默认判定逻辑看GTEST_USE_OWN_TR1_TUPLE默认为 1 的典型情形是编译器无现成 TR1 tuple如较老的 libstdc、QNX 的 QCC、MSVC 2008 等在 gcc ≥ 4.0.0且非 CUDA、非 QNX、非 libc或 MSVC ≥ 2010 时默认为 0。C11 模式下则优先使用tuple提供的std::tuple。这些宏需同时作用于 gtest 编译与你的测试编译。多线程测试支持在 pthread 库可用的平台上Google Test 是线程安全的。#include gtest/gtest.h之后可用GTEST_IS_THREADSAFE宏判断若其被定义为 1 则线程安全未定义则不安全gtest-port.h 中该宏由GTEST_HAS_PTHREAD及平台宏推导得出。若自动检测不准可强制指定-DGTEST_HAS_PTHREAD1 # 强制启用 pthread -DGTEST_HAS_PTHREAD0 # 强制禁用 pthread源码显示其默认值为GTEST_OS_LINUX || GTEST_OS_MAC || GTEST_OS_HPUX || GTEST_OS_QNX || GTEST_OS_FREEBSD || GTEST_OS_NACL且GTEST_HAS_PTHREAD为真时会自动#include pthread.h。使用 pthread 时可能需要为编译器和/或链接器追加选择 pthread 库的标志否则会报链接错误——用 CMake 或 Autotools 脚本时该工作已自动完成自建脚本则需查阅编译器/链接器手册。以共享库DLL方式使用gtest 体积紧凑多数用户为简单起见选择静态链接。若想以共享库方式使用Windows 上即 DLL需要编译gtest 自身时加-DGTEST_CREATE_SHARED_LIBRARY1并告知链接器产出共享库细节查阅链接器手册编译你的测试时加-DGTEST_LINKED_AS_SHARED_LIBRARY1注意虽然当前某些编译器如 GCC不加上述标志也能工作但 README 明确建议始终加上——未来 gtest 若优化库加载速度缺失这些宏的构建脚本可能被破坏。从 gtest-port.h 的导出宏定义可见GTEST_API_的可见性正是依据这两个宏GTEST_LINKED_AS_SHARED_LIBRARY/GTEST_CREATE_SHARED_LIBRARY来决定的。规避宏名冲突C 宏不遵守命名空间两套库若定义了同名宏同时#include时必然冲突。若 gtest 的某个宏与其他库冲突可用如下方式让 gtest 改名-DGTEST_DONT_DEFINE_FOO1其中FOO目前可取值FAIL、SUCCEED、TEST——定义后 gtest 将把该宏改名为GTEST_FOO。例如-DGTEST_DONT_DEFINE_TEST1之后定义测试就必须写GTEST_TEST(SomeTest, DoesThis) { ... }而不是原来的TEST(SomeTest, DoesThis) { ... }深入开发 gtest 自身Pump 代码生成器若你要修改 gtest 源码README 特别提醒不要直接编辑由脚本生成的文件而应修改对应的.pump模板文件再运行 Python 脚本 scripts/pump.py 重新生成。仓库中可见的生成模板包括gtest-param-util-generated.h.pump生成gtest-param-util-generated.hgtest-tuple.h.pump生成gtest-tuple.hgtest-param-test.h.pump生成gtest-param-test.hgtest-type-util.h.pump生成gtest-type-util.hPump 的用法详见仓库内 docs/PumpManual.md。修改模板并重新生成后务必按前文构建 gtest 自身测试一节用-Dgtest_build_testsON编译并make test回归验证。在 miniblink49 中的实践建议作为以 Chromium/Blink 为基础的浏览器内核miniblink49 的测试场景高度依赖跨平台构建与宏调优这与 gtest README 的核心诉求完全契合静态库优先浏览器内核的测试产物通常随主工程静态链接gtest 体积紧凑默认静态编译libgtest.a即可避免 DLL 分发负担Windows 注意运行时一致性若在 Windows 上采用遗留的msvc/工程务必保持 gtest 与测试代码的/MD、/MT选项一致pthread 与多线程测试浏览器内核的多线程特性渲染线程、网络线程、JS 引擎线程意味着测试框架本身必须是线程安全的编译时保留-pthread/ 不定义GTEST_HAS_PTHREAD0并可通过GTEST_IS_THREADSAFE在测试代码中做条件编译宏冲突防护大型内核工程常引入大量第三方头文件若与FAIL、SUCCEED、TEST等宏冲突直接使用-DGTEST_DONT_DEFINE_*系列宏规避而无需改动 gtest 源码。以上路径均可在仓库中直接查看gtest 头文件目录、gtest 源码目录、CMake 脚本、官方样例。【免费下载链接】miniblink49a lighter, faster browser kernel of blink to integrate HTML UI in your app. 一个小巧、轻量的浏览器内核用来取代wke和libcef项目地址: https://gitcode.com/GitHub_Trending/mi/miniblink49创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 miniblink49 仓库内 Google Test 构建指南：从源码编译、CMake 集成到宏调优的完整实践
miniblink49 仓库内 Google Test 构建指南从源码编译、CMake 集成到宏调优的完整实践【免费下载链接】miniblink49a lighter, faster browser kernel of blink to integrate HTML UI in your app. 一个小巧、轻量的浏览器内核用来取代wke和libcef项目地址: https://gitcode.com/GitHub_Trending/mi/miniblink49导读本指南以 v8_5_7/testing/gtest/README.md 为核心骨架系统讲解如何将 Google C Testing FrameworkGoogle Test集成进大型 C 项目。miniblink49 是一个以 Chromium/Blink 为基底、用于在应用中嵌入 HTML UI 的轻量浏览器内核其 v8_5_7 测试工具链中完整保留了 Google Test 源码树头文件、实现、样例、构建脚本一应俱全。读完本文你将掌握在 Linux/Windows/macOS 上从零编译 gtest 静态库与动态库、用 CMake 生成跨平台构建工程、构建官方样例与 gtest 自测、以及通过一组GTEST_*编译宏按需裁剪tuple 选择、线程支持、宏名冲突规避等的完整实战方案。仓库中的 Google Test 源码布局在动手编译前先认清 miniblink49 仓库中 Google Test 的目录结构以下路径均相对仓库根目录v8_5_7/testing/gtest/include全部公共头文件核心是 gtest/gtest.h以及内部实现头 gtest/internal/gtest-port.h、gtest-internal.h 等v8_5_7/testing/gtest/src全部实现源文件包括聚合编译入口 gtest-all.cc、提供main()的 gtest_main.cc、死亡测试 gtest-death-test.cc 等v8_5_7/testing/gtest/samples官方示例sample1_unittest等v8_5_7/testing/gtest/make/MakefileGNU make 构建脚本v8_5_7/testing/gtest/CMakeLists.txtCMake 跨平台构建脚本msvc/、xcode/、codegear/面向 Visual Studio、Xcode、CodeGear 的传统工程README 明确标注为 Legacy遗留脚本仅作便利保留。本文所有命令中的${GTEST_DIR}均指 v8_5_7/testing/gtest请按你解压或检出到的实际路径替换。通用构建流程手动集成第一步编译 gtest 库本体README 推荐的核心做法是只编译一个源文件src/gtest-all.cc。从该文件源码可以看到它通过#include依次拉入gtest.cc、gtest-death-test.cc、gtest-filepath.cc、gtest-port.cc、gtest-printers.cc、gtest-test-part.cc、gtest-typed-test.cc全部实现因此单文件编译即可得到完整测试框架。编译时有两处头文件搜索路径要求将${GTEST_DIR}/include放入系统头文件搜索路径-isystem避免编译器对 gtest 头产生告警将${GTEST_DIR}放入普通头文件搜索路径-I使src/gtest-all.cc内的相对包含#include src/gtest.cc可被解析。在 Linux 类系统 gcc 环境下g -isystem ${GTEST_DIR}/include -I${GTEST_DIR} \ -pthread -c ${GTEST_DIR}/src/gtest-all.cc ar -rv libgtest.a gtest-all.o必须加-pthreadREADME 明确指出 We need-pthreadas Google Test uses threads。第二步编译并链接你的测试编写测试源文件your_test.cc后编译时仍将${GTEST_DIR}/include作为系统头路径链接 gtest 静态库与其他必要库g -isystem ${GTEST_DIR}/include -pthread path/to/your_test.cc libgtest.a \ -o your_test这里链接的是不含main()的libgtest.a因此你的测试文件需自行提供main()。若希望使用框架自带的main()可改用 src/gtest_main.cc 编译出的gtest_main.a进行链接。借助官方 Makefile 快速上手make/Makefile 是 README 提到的现成起点它不构建 gtest 自身测试只产出 gtest 库与一个样例测试。该 Makefile 的关键变量与规则值得逐行研读GTEST_DIR ..指向 gtest 根目录相对 Makefile 位置移动到你的工程时需调整USER_DIR ../samples用户代码目录指向官方样例CPPFLAGS -isystem $(GTEST_DIR)/include把 gtest 头设为系统目录抑制其内部告警CXXFLAGS -g -Wall -Wextra -pthread调试信息、完整告警、线程支持目标gtest.a由gtest-all.o归档而成gtest_main.a额外加入gtest_main.o目标sample1_unittest链接gtest_main.a样例未自定义main()。在默认环境配置正确的前提下README 给出的三步即可直接验证cd ${GTEST_DIR}/make make ./sample1_unittest若报错则根据报错微调make/Makefile中的编译/链接选项例如针对非 Linux 平台的 pthread 标志差异Makefile 内有详细注释说明。使用 CMake 跨平台构建基本构建流程CMake 的价值在于一次编写、多平台生成原生构建工程。标准工作流mkdir mybuild # 创建构建输出目录 cd mybuild cmake ${GTEST_DIR} # 生成原生构建脚本在 *nix 上会生成Makefile直接执行make即可构建 gtest在 Windows 上安装了 Visual Studio会生成gtest.sln与多个.vcproj工程文件可在 VS 中构建在 macOS安装了 Xcode会生成.xcodeproj工程。构建官方样例若需要同时构建 gtest 的 sample 程序将 cmake 命令替换为cmake -Dgtest_build_samplesON ${GTEST_DIR}该开关与 CMakeLists.txt 中的option(gtest_build_samples Build gtests sample programs. OFF)一一对应默认 OFF。构建 gtest 自身测试开发 gtest 时修改 gtest 源码后建议编译并跑通 gtest 自带的测试套件mkdir mybuild cd mybuild cmake -Dgtest_build_testsON ${GTEST_DIR}注意部分 gtest 自测由 Python 编写机器上必须装有 Python。若 cmake 报Could NOT find PythonInterp (missing: PYTHON_EXECUTABLE)需显式指定解释器路径cmake -DPYTHON_EXECUTABLEpath/to/python -Dgtest_build_testsON ${GTEST_DIR}*nix 下构建用make运行测试用make test正常情况下全部通过。该开关对应 CMakeLists 的option(gtest_build_tests Build all of gtests own tests. OFF)。CMake 提供的其他开关从 CMakeLists.txt 可看到更多可调项默认值以源码为准BUILD_SHARED_LIBS默认 OFF是否将 gtest 构建为共享库Windows 上即 DLLgtest_disable_pthreads默认 OFF是否禁用 gtest 对 pthread 的使用对应下面将要介绍的GTEST_HAS_PTHREAD0。遗留构建脚本Legacy Build Scripts在采用 CMake 之前gtest 长期提供手写维护的 Visual Studio、Xcode、Autotools 工程。README 明确提示这些脚本不再积极维护仅作便利保留强烈建议优先采用前述通用编译或 CMake 方案。如需使用要点如下Visual Studio打开msvc/目录下的gtest.sln或gtest-md.sln。命名后缀-md表示使用 Microsoft 运行时库的 DLL 版本/MD或/MDd不带后缀的表示静态运行时/MT或/MTd。必须保证编译 gtest 与编译你的测试代码使用相同的运行时选项否则会出现运行时库冲突。若使用 VS2005 及以上版本官方推荐-md版本因为/MD是这些版本新工程的默认值macOS / Xcode用 Xcode 打开xcode/下的gtest.xcodeproj构建 gtest target通用二进制框架会输出到构建目录默认xcode/build。也可在命令行执行xcodebuild该命令会构建默认位置下的gtest.frameworkRelease 配置。若使用 Xcode 4.x 及以上需二选一修改xcode/Config/General.xconfig注释掉SDKROOT、MACOS_DEPLOYMENT_TARGET、GCC_VERSION三个选项代价是无法再针对更早的 macOS 版本安装早期版本的 SDK。按需调优一组 GTEST_* 控制宏Google Test 面向多种环境默认配置在某些平台上可能不理想可通过在编译命令行定义形如GTEST_XYZ的宏赋值为 1 或 0 启用/禁用特性进行调优。这些宏的权威完整清单见 include/gtest/internal/gtest-port.h如GTEST_HAS_EXCEPTIONS、GTEST_HAS_RTTI、GTEST_HAS_POSIX_RE、GTEST_HAS_SEH、GTEST_LANG_CXX11等。注意该头文件约定用户未定义的宏会被自动补默认值且统一用#if而非#ifdef判定参见文件头部注释因此这类宏在#include后总是处于已定义状态。选择 TR1 tuple 库部分 gtest 特性依赖 C TR1 的 tuple 库而并非所有编译器都自带。好消息是 gtest 内置了一份够用的 TR1 tuple 子集实现gtest-tuple.h编译器缺少 TR1 tuple 时会自动启用。通常无需关心选用哪个 tuple 实现但若你的项目已在使用 TR1 tuple则必须让 gtest 与项目保持一致否则两套 tuple 实现会冲突-DGTEST_USE_OWN_TR1_TUPLE0 # 使用项目已有的 TR1 tuple -DGTEST_USE_OWN_TR1_TUPLE1 # 强制使用 gtest 内置 tuple -DGTEST_HAS_TR1_TUPLE0 # 完全禁用 tuple所有依赖 tuple 的特性关闭从 gtest-port.h 的默认判定逻辑看GTEST_USE_OWN_TR1_TUPLE默认为 1 的典型情形是编译器无现成 TR1 tuple如较老的 libstdc、QNX 的 QCC、MSVC 2008 等在 gcc ≥ 4.0.0且非 CUDA、非 QNX、非 libc或 MSVC ≥ 2010 时默认为 0。C11 模式下则优先使用tuple提供的std::tuple。这些宏需同时作用于 gtest 编译与你的测试编译。多线程测试支持在 pthread 库可用的平台上Google Test 是线程安全的。#include gtest/gtest.h之后可用GTEST_IS_THREADSAFE宏判断若其被定义为 1 则线程安全未定义则不安全gtest-port.h 中该宏由GTEST_HAS_PTHREAD及平台宏推导得出。若自动检测不准可强制指定-DGTEST_HAS_PTHREAD1 # 强制启用 pthread -DGTEST_HAS_PTHREAD0 # 强制禁用 pthread源码显示其默认值为GTEST_OS_LINUX || GTEST_OS_MAC || GTEST_OS_HPUX || GTEST_OS_QNX || GTEST_OS_FREEBSD || GTEST_OS_NACL且GTEST_HAS_PTHREAD为真时会自动#include pthread.h。使用 pthread 时可能需要为编译器和/或链接器追加选择 pthread 库的标志否则会报链接错误——用 CMake 或 Autotools 脚本时该工作已自动完成自建脚本则需查阅编译器/链接器手册。以共享库DLL方式使用gtest 体积紧凑多数用户为简单起见选择静态链接。若想以共享库方式使用Windows 上即 DLL需要编译gtest 自身时加-DGTEST_CREATE_SHARED_LIBRARY1并告知链接器产出共享库细节查阅链接器手册编译你的测试时加-DGTEST_LINKED_AS_SHARED_LIBRARY1注意虽然当前某些编译器如 GCC不加上述标志也能工作但 README 明确建议始终加上——未来 gtest 若优化库加载速度缺失这些宏的构建脚本可能被破坏。从 gtest-port.h 的导出宏定义可见GTEST_API_的可见性正是依据这两个宏GTEST_LINKED_AS_SHARED_LIBRARY/GTEST_CREATE_SHARED_LIBRARY来决定的。规避宏名冲突C 宏不遵守命名空间两套库若定义了同名宏同时#include时必然冲突。若 gtest 的某个宏与其他库冲突可用如下方式让 gtest 改名-DGTEST_DONT_DEFINE_FOO1其中FOO目前可取值FAIL、SUCCEED、TEST——定义后 gtest 将把该宏改名为GTEST_FOO。例如-DGTEST_DONT_DEFINE_TEST1之后定义测试就必须写GTEST_TEST(SomeTest, DoesThis) { ... }而不是原来的TEST(SomeTest, DoesThis) { ... }深入开发 gtest 自身Pump 代码生成器若你要修改 gtest 源码README 特别提醒不要直接编辑由脚本生成的文件而应修改对应的.pump模板文件再运行 Python 脚本 scripts/pump.py 重新生成。仓库中可见的生成模板包括gtest-param-util-generated.h.pump生成gtest-param-util-generated.hgtest-tuple.h.pump生成gtest-tuple.hgtest-param-test.h.pump生成gtest-param-test.hgtest-type-util.h.pump生成gtest-type-util.hPump 的用法详见仓库内 docs/PumpManual.md。修改模板并重新生成后务必按前文构建 gtest 自身测试一节用-Dgtest_build_testsON编译并make test回归验证。在 miniblink49 中的实践建议作为以 Chromium/Blink 为基础的浏览器内核miniblink49 的测试场景高度依赖跨平台构建与宏调优这与 gtest README 的核心诉求完全契合静态库优先浏览器内核的测试产物通常随主工程静态链接gtest 体积紧凑默认静态编译libgtest.a即可避免 DLL 分发负担Windows 注意运行时一致性若在 Windows 上采用遗留的msvc/工程务必保持 gtest 与测试代码的/MD、/MT选项一致pthread 与多线程测试浏览器内核的多线程特性渲染线程、网络线程、JS 引擎线程意味着测试框架本身必须是线程安全的编译时保留-pthread/ 不定义GTEST_HAS_PTHREAD0并可通过GTEST_IS_THREADSAFE在测试代码中做条件编译宏冲突防护大型内核工程常引入大量第三方头文件若与FAIL、SUCCEED、TEST等宏冲突直接使用-DGTEST_DONT_DEFINE_*系列宏规避而无需改动 gtest 源码。以上路径均可在仓库中直接查看gtest 头文件目录、gtest 源码目录、CMake 脚本、官方样例。【免费下载链接】miniblink49a lighter, faster browser kernel of blink to integrate HTML UI in your app. 一个小巧、轻量的浏览器内核用来取代wke和libcef项目地址: https://gitcode.com/GitHub_Trending/mi/miniblink49创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考