CMake源码编译与find_package典型流程疑问：跨平台依赖构建冲突

看起来你踩了CMake依赖管理里一个很典型的坑——循环依赖+交叉编译上下文混淆，而且你可能没抓住CMake中"构建树内依赖"和"系统级依赖"的核心区别，以及依赖方向的合理性问题。咱们一步步拆解你遗漏的要点：

1. 首先要质疑：厂商库A为什么会依赖自研库B？ #

这本身就不符合常规的依赖逻辑——厂商提供的库通常是被依赖的一方，而不是反过来依赖你的自研代码。除非A是一个插件框架，需要B作为插件实现，但这种情况下A的find_package(B)应该是可选的或者仅针对特定构建场景（比如Windows下的本地插件开发）。如果这个依赖是厂商硬加的且不合理，那第一步应该确认是否可以通过CMake选项禁用它，这是最根本的解决思路。

2. 混淆了"系统安装依赖"和"构建树内源码依赖"的工作流 #

场景1的find_package(A)是CMake的系统级依赖查找逻辑——它找的是已经安装到系统（或指定路径）的预编译库。但场景2是全源码交叉编译，你需要把A和B都作为当前构建树的子项目来处理，这时候不应该用include(B/CMakeLists.txt)（这会把B的代码直接注入当前作用域，容易引发变量冲突），而是应该用add_subdirectory()来添加子项目，并且让CMake自动处理它们的依赖顺序。

如果A必须依赖B，那正确的源码构建流应该是：

• 先添加B的子目录：add_subdirectory(path/to/B)
• 再添加A的子目录：add_subdirectory(path/to/A)
• 同时，修改A的CMakeLists（如果允许的话），把find_package(B)替换为直接链接B的目标：target_link_libraries(A PRIVATE B)——因为B已经在当前构建树里了，不需要通过find_package去找。

如果不能修改A的CMakeLists（厂商源码不可改），那你需要告诉CMake在构建A时，优先从当前构建树里找B，而不是系统路径：

# 在添加A之前设置，让find_package优先找构建树内的目标
set(CMAKE_FIND_PACKAGE_PREFER_CONFIG ON)
# 把B的构建目录加入查找路径
list(APPEND CMAKE_PREFIX_PATH ${CMAKE_CURRENT_BINARY_DIR}/B)
add_subdirectory(path/to/A)

3. 没有针对不同构建目标（Windows/Android）隔离依赖逻辑 #

你提到用MSVC和Android的条件标志处理，这方向是对的，但你可能没把条件判断放在正确的层级。比如，A的find_package(B)应该只在Windows本地构建且A需要B的情况下生效，交叉编译时完全可以禁用这个依赖：

在A的CMakeLists里（如果能修改的话）：

# 新增选项控制是否依赖B
option(A_USE_B "Enable B support for A" ON)
# 只有Windows构建且启用选项时才查找B
if(A_USE_B AND WIN32)
  find_package(B REQUIRED)
  target_link_libraries(A PRIVATE B::B)
endif()

然后交叉编译Android时，在CMake配置阶段传递参数：-D A_USE_B=OFF，这样A就不会去查找B了。

4. 误用了include()而不是add_subdirectory()管理子项目 #

include(B/CMakeLists.txt)会把B的CMake代码直接插入当前CMakeLists的作用域，这会导致变量污染，而且CMake无法跟踪B作为独立子项目的构建顺序。而add_subdirectory()会创建一个独立的作用域，自动处理子项目的构建目标，并且可以通过EXCLUDE_FROM_ALL等参数控制是否默认构建该子项目，这才是CMake管理多源码项目的标准方式。

总结一下你遗漏的核心要点 #

CMake的依赖管理核心是区分"已安装的预编译依赖"和"当前构建树内的源码依赖"，并且通过目标（target）而非全局命令来传递依赖。你之前的问题本质是混合了两种依赖模式，且没有正确处理循环依赖（A找B，而B又需要A）的构建顺序。

如果A必须依赖B，那源码构建时一定要保证B先被构建，并且让A能找到B的构建目标；如果这个依赖是非必须的，那就通过条件选项在交叉编译时禁用它。

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