如何在OpenWrt中使用GoogleTest？交叉编译与测试方案咨询

方案1：创建独立测试包D #

• 好处：
  • 测试代码和业务代码彻底隔离，不会把GTest的依赖混进C包的编译流程，完全不影响主包的交叉编译进度
  • 可以直接在本地x86/x64主机上编译D包跑测试——毕竟GTest交叉编译麻烦，你只要把A、B、C的头文件和本地编译的静态库链接过来，就能先把C的核心逻辑测个遍，不用碰ARM交叉编译的坑
  • OpenWrt的包管理本来就支持独立包，新增D包就是在package目录下建个新文件夹，写个Makefile指定依赖A、B、C就行，没什么复杂的配置成本
• 麻烦点：
  • 得多维护一个包的Makefile，增加一点点配置工作量
  • 如果非要在ARM设备上跑测试，还是得解决GTest交叉编译的问题，但要是本地测试能覆盖大部分场景，这个问题可以先放一放

方案2：将测试作为C包的一部分构建 #

• 好处：
  • 测试代码和C的业务代码在同一目录，改完代码直接就能触发测试编译，关联维护起来顺手
  • 不需要额外新建包，在C包的Makefile里加个测试目标即可
• 麻烦点：
  • 必须先搞定GTest的交叉编译，不然C包的编译流程会被测试依赖卡住，连主包都没法正常构建
  • 一不小心测试代码就会被打包进生产固件，平白增加体积，不符合OpenWrt轻量的路子

优先推荐：独立测试包D #

结合你现在GTest交叉编译搞不定的情况，优先选D包方案，理由很直接：

1. 先在本地主机把C的逻辑测透：不用碰交叉编译GTest的麻烦事，本地编译D包依赖A、B、C的主机版本，用GTest跑所有用例，核心逻辑没问题了再去管ARM那边
2. 完全不影响主包开发：C包该怎么交叉编译就怎么来，测试依赖的问题根本碰不到主流程
3. 真要在ARM上跑测试的时候，再针对性解决GTest的交叉编译——比如找OpenWrt官方源里有没有现成的GTest包，或者手动改GTest的编译配置适配交叉链就行

实操要点 #

• 在OpenWrt的package目录下新建test-d文件夹，写Makefile的时候指定DEPENDS:=+A +B +C，然后可以选择编译成主机版本（本地测试）或者ARM目标版本
• 测试代码直接引入A、B、C的头文件，链接它们的静态库和GTest库即可
• 用CONFIG_PACKAGE_TEST_D开关控制要不要编译测试包，别让测试代码混进生产固件里

内容的提问来源于stack exchange，提问作者Preston Thomson