CMake中add_subdirectory引入依赖是否需配合使用find_package

不需要。
add_subdirectory和find_package是CMake引入第三方依赖的两套独立、可二选一的机制，不存在强制配套关系：

• find_package的核心逻辑是搜索系统/用户指定路径下预安装的第三方包配置文件（即报错提到的FooConfig.cmake/foo-config.cmake），导入预编译好的包目标，整个过程不会触发第三方库的源码编译流程。
• add_subdirectory是直接将源码树内嵌入的第三方库的完整CMake构建逻辑纳入当前工程构建流，第三方库会作为主工程构建流程的一部分直接参与编译，其导出的目标、配置会直接进入当前工程的CMake上下文，不需要额外的查找步骤。

你遇到的报错本质是冗余调用find_package(foo)导致的：add_subdirectory执行时不会为find_package生成对应的Config.cmake搜索入口，只要你没有提前将foo安装到系统搜索路径、也没有手动给find_package指定foo的安装路径，它必然会报找不到配置文件的错误，直接删除多余的find_package调用即可。如果需要兼容「优先使用系统预装foo，找不到再用源码树内嵌版本」的场景，可以加一层判断：

find_package(foo QUIET)
if(NOT foo_FOUND)
    add_subdirectory(3rdparty/foo) # 替换为你本地foo源码的实际相对路径
endif()

遵循现代CMake的目标导向配置原则即可，核心操作点如下：

• 保证调用顺序正确：必须在所有引用foo目标的CMake逻辑解析前，执行add_subdirectory引入foo。最稳妥的做法是在顶层CMakeLists.txt中，先统一add_subdirectory引入所有第三方依赖，再往下引入自身业务代码的子目录。
• 优先使用第三方库导出的目标链接，不要手动全局配置路径：规范的CMake工程在通过add_subdirectory引入后，会导出带命名空间的使用目标（通常格式为foo::foo、foo::core这类），业务组件需要依赖foo时，直接在自身的target_link_libraries中关联该目标即可：

  # 业务目标示例：可执行文件/动态静态库都适用
  add_executable(my_biz_app src/main.cpp)
  # 链接foo导出的目标，其绑定的头文件路径、编译选项、库依赖会自动传递
  target_link_libraries(my_biz_app PRIVATE foo::foo)
  

  这种方式下，foo目标上配置的INTERFACE_INCLUDE_DIRECTORIES（头文件搜索路径）、INTERFACE_LINK_LIBRARIES（依赖库）、INTERFACE_COMPILE_OPTIONS（编译参数）等属性会自动传递给所有链接它的业务目标，不需要手动给每个业务目标单独加头文件路径、库路径。
• 针对不规范的老旧第三方库手动补全目标属性：如果foo是没有导出规范目标的老旧CMake工程，不要用全局的include_directories/link_directories指令配置路径，应该在add_subdirectory之后直接给foo的库目标补全PUBLIC级别的接口属性：

  add_subdirectory(3rdparty/foo)
  # 假设foo的库目标名为foo，头文件存放在其源码目录下的include文件夹
  target_include_directories(foo PUBLIC
      ${CMAKE_CURRENT_SOURCE_DIR}/3rdparty/foo/include
  )
  

  补全后其他业务目标依然直接链接foo目标即可，属性会自动传递，避免全局路径污染。
• 非必要不要给add_subdirectory加EXCLUDE_FROM_ALL参数：该参数会将foo的目标排除在默认构建队列之外，可能导致业务目标链接时找不到foo生成的库文件，如果确实需要加该参数，必须手动将foo的目标配置为对应业务目标的构建依赖。

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