CMake如何正确处理可执行文件之间的依赖关系

你提到的第一种拆分app_lib中间库的方案，才是当前场景下最符合CMake规范、也是业界普遍使用的标准解决方案，完全不属于不规范写法。

方案1（app_lib中间库）的合理性 #

• 完全符合CMake基于目标的设计逻辑：把无入口的业务逻辑拆分为独立库目标，统一管理编译选项、头文件路径、第三方依赖。boost等外部依赖只需要在app_lib的target_link_libraries中声明为PUBLIC，app和test两个可执行目标会自动继承所有依赖配置，不需要重复声明。
• 跨平台兼容性最好：不会涉及不同平台下可执行文件导出符号的差异问题，Windows下不需要额外处理导出表，Linux/macOS下也不需要额外配置位置无关代码等参数。
• 构建效率更高：业务代码仅需要编译一次，修改逻辑后仅需要重新编译app_lib再链接两个可执行文件，不需要重复编译相同的源文件。
• 扩展性更强：后续如果要拆分动态库、新增工具类可执行文件、接入CI测试流水线，都不需要重构现有构建结构。大量开源项目（包括LLVM、CMake自身的测试体系）都采用该结构实现业务代码和测试代码的分离，是经过业界验证的标准实践。

方案2（直接链接app可执行文件）的局限性 #

该方案确实属于非标准的hack用法，仅适合临时测试场景，不推荐在正式项目中使用，核心问题如下：

• 平台兼容性差：Windows下必须给app设置ENABLE_EXPORTS才会生成对应的导出库，Linux下需要额外开启-fPIE等选项，macOS下也有独立的符号导出限制，跨平台构建很容易出现符号找不到的问题。
• 不符合构建语义：app本身是带main入口的可执行目标，链接可执行文件不符合C/C++的常规构建语义，后续修改app的入口逻辑很容易意外影响test的构建。
• 构建效率偏低：业务代码修改后，app和test都需要重新执行完整的链接流程，部分场景下还会出现重复编译的问题。

更轻量的可选方案：OBJECT 目标 #

如果你使用的是CMake 3.12及以上版本，不想生成额外的静态/动态库文件，可以使用OBJECT目标代替传统的静态库app_lib：

# 定义OBJECT目标，编译所有不含main的业务源文件
add_library(app_obj OBJECT
    src/module_a.cpp
    src/module_b.cpp
    # 其他业务源文件
)
# 配置OBJECT目标的头文件路径和依赖，PUBLIC属性会自动传递给后续链接的目标
target_include_directories(app_obj PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/src)
target_link_libraries(app_obj PUBLIC Boost::boost)

# 生成业务可执行文件
add_executable(app src/main.cpp)
target_link_libraries(app PRIVATE app_obj)

# 生成单元测试可执行文件
add_executable(test test/case1.cpp test/case2.cpp)
target_link_libraries(test PRIVATE app_obj)

OBJECT目标不会生成实际的静态/动态库文件，只会把编译得到的目标文件直接提供给后续链接的目标，相比静态库方案可以省略库文件生成的步骤，更适合中小型项目使用，同样完全符合CMake规范。

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