CMake中STATIC库正常触发子目录构建，SHARED库异常问题求助

我之前也碰到过完全一样的问题！当把myRtspClient从静态库改成共享库时，CMake突然就乱了构建顺序，直接因为依赖的JRTPLIB头文件没生成而报错，折腾了好一会儿才搞明白原因。

先看看你当前的CMake代码：

add_subdirectory(../third_party/JRTPLIB ../third_party/JRTPLIB)
include_directories(../third_party/JRTPLIB/src)
#generated from cmakelists of the subdirectory above
...
add_library(myRtspClient STATIC ${SOURCES})

问题根源 #

为什么用STATIC时没问题？因为CMake对静态库的处理会默认保证依赖的子目录先完成构建——毕竟静态库只是把目标文件打包，编译阶段不需要子库的完整产物。但换成SHARED后，共享库在编译阶段就需要依赖的头文件（甚至符号信息），如果没有显式告诉CMake依赖关系，它不会自动推断构建顺序，导致myRtspClient先启动编译，而JRTPLIB生成的头文件还没准备好。

靠谱的解决办法 #

这里有几个逐步优化的方案，亲测有效：

1. 强制指定构建依赖（快速修复）

直接用add_dependencies明确告诉CMake：必须先建好JRTPLIB，再编译myRtspClient。注意要替换成JRTPLIB子目录实际生成的目标名（一般和库名一致）：

add_library(myRtspClient SHARED ${SOURCES})
# 假设JRTPLIB子目录生成的目标是JRTPLIB
add_dependencies(myRtspClient JRTPLIB)

2. 用现代CMake的目标链接（推荐）

如果JRTPLIB是用CMake构建的库目标，直接用target_link_libraries关联，CMake会自动处理依赖顺序，还能帮你自动传递头文件路径，甚至可以删掉include_directories：

add_subdirectory(../third_party/JRTPLIB ../third_party/JRTPLIB)
# 移除手动的include_directories，改用目标链接自动继承头文件
add_library(myRtspClient SHARED ${SOURCES})
target_link_libraries(myRtspClient PRIVATE JRTPLIB)

这种方式是现代CMake的最佳实践，不仅解决了构建顺序问题，还能更清晰地管理依赖的编译选项和头文件。

3. 检查子库的CMake配置（从根源优化）

确保JRTPLIB的CMakeLists.txt里正确设置了头文件的可见性，比如用target_include_directories把src目录设为PUBLIC或INTERFACE：

# 在JRTPLIB的CMakeLists.txt中添加
target_include_directories(JRTPLIB PUBLIC src)

这样当主库链接JRTPLIB时，会自动继承这些头文件路径，不用再手动写include_directories，依赖管理更干净。

总的来说，核心就是SHARED库对依赖的时机要求更严格，不能依赖CMake的默认行为，显式声明依赖或者用现代CMake的目标链接方式才是可靠的解决途径。

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