第一次在别人的工程里翻到find_package(OpenCV REQUIRED)这行代码时我盯着它看了足足两分钟——没有include_directories没有link_directories没有任何硬编码路径一行就搞定了整个第三方库的引入。那会儿我刚从手写 Makefile 的泥潭里爬出来看到这种写法第一反应是这东西是不是有什么魔法。后来自己踩了无数次坑才发现CMake 的find_package既不是魔法也不是黑盒它只是一套约定大于配置的查找机制理解了它的搜索规则和变量命名绝大部分找不到包链接报错版本对不上的问题都能自己解决。这篇内容写给那些已经会写基础 CMakeLists.txt、但一遇到第三方依赖就发怵的朋友也写给想把自己写的库优雅地交给别人用的人。我会把find_package的两种模式、搜索路径顺序、常用变量、真实报错排查以及怎么导出自己的包全部拆开讲一遍。1. 先搞清楚 find_package 到底替你干了什么1.1 从手写路径到包管理的思路转变在没有find_package的年代引入一个第三方库是件很笨重的事。你得先知道自己机器上这个库装在哪头文件在/usr/include/xxx还是/usr/local/include/xxx库文件叫libxxx.so还是libxxx.a然后把这些路径一条条写进 CMakeLists.txt 或者 Makefile。这套做法在只有一台机器的时候没问题一旦换台电脑、换个系统、换个编译环境路径全变构建脚本就报废了。更麻烦的是静态库和动态库混用、Debug 版和 Release 版混用链接顺序不对还会报一堆undefined reference。find_package的核心价值就是把这些我机器上的具体路径抽象成我想要哪个包。你只描述需求比如我要 OpenCV版本不低于 4.5必须有 core 和 imgproc 两个模块至于它在哪、叫什么名字、有什么依赖交给 CMake 自己去查。这套思路和 Linux 包管理器、Python 的 pip、Node 的 npm 是一个路子只是 CMake 的查找结果不是直接给你装好而是把查到的路径、库名、编译选项以变量的形式交回到你的脚本里让你自己决定怎么用。理解了这一点后面所有让人困惑的行为就都好解释了为什么find_package有时能找到有时找不到因为它依赖的是一套约定位置 提示变量的搜索逻辑为什么不同库的用法不一样因为每个库的作者自定义的方式不同。1.2 Module 模式和 Config 模式的本质区别find_package有两条完全不同的查找链路这是初学者最容易混淆的地方。CMake 默认会先尝试 Module 模式找不到再尝试 Config 模式前提是你没有显式指定MODULE或CONFIG关键字。Module 模式查找的是一个叫FindPackageName.cmake的脚本文件。这个文件可能来自三处你自己项目里通过CMAKE_MODULE_PATH添加的目录或者 CMake 安装目录下自带的Modules/文件夹。CMake 官方为一大批常见库预置了这样的脚本比如FindThreads.cmake、FindZLIB.cmake、FindGit.cmake。这类脚本的特点是由 CMake 社区在维护它会尝试各种手段在系统里把库找出来然后把结果写进一堆约定俗成的变量里。Config 模式查找的是PackageNameConfig.cmake或者小写包名-config.cmake。这个文件不是 CMake 自带的而是库的作者在安装自己的库时顺带装上去的。现代主流的库比如 OpenCV、Protobuf、Qt、gRPC都走这条路。这种模式的好处是只有库的作者最清楚自己的库该怎么被链接、有哪些依赖、编译选项是什么所以他们通过这个文件直接把导入目标Imported Target交给你你只需要target_link_libraries就能用。区别有多大举个直观的例子。Module 模式下你拿到的是ZLIB_LIBRARIES和ZLIB_INCLUDE_DIRS这两个变量得自己拼target_include_directories和target_link_libraries。Config 模式下你拿到的是一个叫ZLIB::ZLIB的目标直接写进target_link_libraries就完事头文件路径、编译选项、依赖关系全都在这个目标里封装好了。提示新项目优先使用 Config 模式的目标写法变量写法是历史遗留容易漏掉依赖项和编译选项尤其是传递性依赖。1.3 什么时候该用哪种模式判断标准其实很简单。如果这个库是你自己装的、有官方安装包、版本比较新优先走 Config 模式直接用它提供的命名空间目标。如果这个库是系统包管理器装的、版本比较旧、或者根本没有提供 Config 文件那就只能靠 Module 模式或者干脆自己写一个FindXXX.cmake。还有一种情况是两者都存在但你想强制指定。比如某个系统上同时装了多个版本的 OpenCVModule 模式可能找到了老版本而你想要的 Config 文件在/opt/opencv/lib/cmake/opencv4/下。这时候用find_package(OpenCV CONFIG REQUIRED)强制走 Config 模式再用OpenCV_DIR变量把路径指过去结果就确定下来了。我自己项目里的习惯是能用 Config 就用 Config因为它是库作者亲自维护的信息最准确。只有碰到 CMake 自带 Find 脚本覆盖的库像Threads、Git、ZLIB才用 Module 模式这类脚本经过多年打磨稳定性很好。2. 搜索路径与核心变量找不到包的根因都在这2.1 CMake 到底按什么顺序找不管哪种模式CMake 都是按一串预设路径顺序往下找的找到第一个就停。理解这个顺序等于掌握了排查问题的地图。下面这张表是 Config 模式下大致的搜索优先级从高到低排列。优先级搜索位置说明1PackageName_ROOT变量与缓存变量CMake 3.12 引入最高优先级适合在 CI 中精确指定2PackageName_DIR缓存变量直接指向包含 Config 文件的目录最精准3CMAKE_PREFIX_PATH通用前缀列表会去每个前缀下的lib/cmake/xxx等子目录找4CMAKE_FRAMEWORK_PATH、CMAKE_APPBUNDLE_PATHmacOS 平台相关5PATH环境变量从可执行文件路径反推同级目录6系统默认路径Linux 下通常是/usr/local、/usrWindows 下是注册表记录的安装位置这里有个容易踩的坑CMAKE_PREFIX_PATH不是让你填库的完整路径而是填一个前缀。CMake 会在这个前缀下面按固定规律去翻比如prefix/lib/cmake/PackageName/、prefix/share/cmake/PackageName/、prefix/lib/PackageName/cmake/等等。很多人直接把lib/cmake/OpenCV这种深层目录填进去结果反而找不到因为 CMake 又往下拼接了一层。注意如果填了前缀还是找不到先用cmake --debug-find跑一遍它会打印出每一个它尝试过的路径比靠猜快得多这个选项需要 CMake 3.23 及以上老版本可以用set(CMAKE_FIND_DEBUG_MODE ON)。2.2 那些你必须认识的变量每一个包查找完之后CMake 都会在缓存里留下一些变量搞懂命名规则你就能在脚本里灵活使用查找结果。变量名含义适用模式Pkg_FOUND是否找到布尔值通用Pkg_DIRConfig 文件所在目录可用于手动覆盖ConfigPkg_VERSION找到的版本号通用Pkg_INCLUDE_DIRS头文件目录列表ModulePkg_LIBRARIES库文件列表ModulePkg_CONFIGConfig 文件的完整路径ConfigCMAKE_PREFIX_PATH全局搜索前缀影响所有包通用其中Pkg_DIR是最有用的一个。当你确认某个包在机器上但 CMake 就是找不到直接命令行传-DOpenCV_DIR/opt/opencv/lib/cmake/opencv4就能立刻解决。这个变量一旦被写进缓存后续构建都会用它不用每次都传。我得提醒一句Pkg_DIR写进缓存后是有粘性的。如果你后来升级了库、换了路径但没有清缓存CMake 会一直用旧路径报出各种莫名其妙的错误。我遇到过最典型的一次是库升级后头文件结构变了但缓存里还指着老目录编译时找不到某个头文件排查了半小时才发现是缓存在作祟。删掉CMakeCache.txt或者整个 build 目录重新生成问题立刻消失。2.3 版本约束、组件和要求级别怎么组合find_package的完整签名参数不少但日常真正高频使用的就那几个把它们组合对了脚本的可维护性能提升一大截。find_package(Qt6 6.5 REQUIRED COMPONENTS Core Widgets Network OPTIONAL_COMPONENTS Sql)这行的意思是我要 Qt6版本至少 6.5必须有 Core、Widgets、Network 三个组件Sql 组件有就用没有也行。REQUIRED表示找不到就直接报错终止配置如果不加这个关键字找不到时只会把Qt6_FOUND设成假由你自己判断。版本约束的写法有几种find_package(Foo 1.2)表示要求不低于 1.2find_package(Foo 1.2 EXACT)表示必须正好是 1.2CMake 3.19 之后还支持区间写法find_package(Foo 1.2...1.9)表示主版本 1 内次版本不低于 2 不高于 9。COMPONENTS的作用是把大包拆开按需索取。像 Qt、Boost 这种库包含几十个子模块全都要会拖慢配置、增加依赖。用组件机制可以精确描述需要哪几块Config 文件里的check_required_components会负责校验。提示QUIET关键字会关闭查找过程中的提示信息适合在脚本里做探测式查找用比如先试着找某个可选依赖找不到就降级到别的实现路径。这里补一个实操细节当你在顶层 CMakeLists 里写了find_package(Foo REQUIRED)而Foo本身依赖Bar那么 Config 文件内部通常会用find_dependency(Bar)自动把Bar也找进来。如果Bar的查找失败报错信息里会明确指出是Foo的配置过程失败而不是简单地告诉你Foo没找到。看到这类嵌套报错别急着怀疑Foo先去解决Bar的问题。3. 动手实操把真实第三方库接进你的工程3.1 一个最小可用的集成模板先看一个能直接抄的骨架我拿 zlib 举例它在绝大多数系统上都有且 CMake 自带FindZLIB.cmake适合当第一个练手对象。cmake_minimum_required(VERSION 3.16) project(demo_find_pkg CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 优先尝试 Config 模式找不到再退回 Module 模式 find_package(ZLIB REQUIRED) if(NOT ZLIB_FOUND) message(FATAL_ERROR zlib 未找到请先安装开发包) endif() message(STATUS zlib 版本: ${ZLIB_VERSION_STRING}) message(STATUS zlib 头文件: ${ZLIB_INCLUDE_DIRS}) message(STATUS zlib 库文件: ${ZLIB_LIBRARIES}) add_executable(demo main.cpp) # 如果有导入目标就用目标没有就退回变量写法 if(TARGET ZLIB::ZLIB) target_link_libraries(demo PRIVATE ZLIB::ZLIB) else() target_include_directories(demo PRIVATE ${ZLIB_INCLUDE_DIRS}) target_link_libraries(demo PRIVATE ${ZLIB_LIBRARIES}) endif()这段代码里有个值得说的设计判断TARGET ZLIB::ZLIB是否存在。因为在不同的 CMake 版本和不同的系统上zlib 的查找结果可能不一样——老版本FindZLIB.cmake只提供变量3.16 之后才补上了导入目标。写这种兼容分支虽然多几行但能保证脚本在团队成员的机器上都能跑通省掉大量我这儿能编译你那儿不行的扯皮。message(STATUS ...)这几行在调试阶段非常有用。它会把查找结果直接打印在配置输出里你一眼就能看到 CMake 到底找到了哪个版本、哪个路径。我习惯在项目初期把它留着等依赖稳定了再删掉避免输出太吵。3.2 Config 模式实战以 OpenCV 为例OpenCV 是典型的 Config 模式库它安装后会在lib/cmake/opencv4/下放一堆文件包括OpenCVConfig.cmake、OpenCVConfig-version.cmake、OpenCVModules.cmake等。find_package(OpenCV 4.5 REQUIRED COMPONENTS core imgproc highgui) if(NOT OpenCV_FOUND) message(FATAL_ERROR OpenCV 4.5 未找到) endif() add_executable(vision_demo main.cpp) target_link_libraries(vision_demo PRIVATE ${OpenCV_LIBS} ) target_include_directories(vision_demo PRIVATE ${OpenCV_INCLUDE_DIRS} )这里用的是 OpenCV 传统的变量写法OpenCV_LIBS和OpenCV_INCLUDE_DIRS。它其实也提供了导入目标名字是opencv_core、opencv_imgproc这种不带命名空间的。我在实际项目里更推荐用目标写法因为变量写法会把所有组件的头文件路径和库都拼在一起粒度太粗。target_link_libraries(vision_demo PRIVATE opencv_core opencv_imgproc opencv_highgui )目标写法还有个隐性好处Debug 和 Release 的库路径分别在IMPORTED_LOCATION_DEBUG和IMPORTED_LOCATION_RELEASE里CMake 会根据当前的构建类型自动选你不用手动判断。而变量写法拿到的是一个混合列表某些库的OpenCV_LIBS可能同时包含 debug 和 release 两个版本链接时容易出问题。配置过程中如果 OpenCV 没找到最有效的办法是直接指定目录cmake -S . -B build -DOpenCV_DIR/opt/opencv/lib/cmake/opencv4这条路走通的概率远高于反复折腾CMAKE_PREFIX_PATH。3.3 找不到包的四步排查法排查find_package失败我总结了一个固定顺序按这个走基本不会漏。第一步确认库到底装没装、装在哪。Linux 下可以先看包管理器有没有装开发包很多人只装了运行时库没装-dev或-devel包自然找不到头文件和 Config 文件。手动确认一下 Config 文件是否存在ls一下预期目录。第二步打开调试输出。用cmake --debug-find -S . -B build或者临时set(CMAKE_FIND_DEBUG_MODE ON)观察 CMake 访问过哪些路径。这一步能立刻定位是路径没包含还是路径包含了但文件名不对。第三步强制指定Pkg_DIR。如果调试输出显示它压根没去你期望的目录直接把这个变量指过去。这一步能排除掉 90% 的路径问题。第四步检查版本和组件要求。有时候包确实找到了但版本不满足CMake 的报错信息会写成找到 3.2但要求 4.5这时候要么放宽要求要么换库版本。现象常见原因处理方式完全没查找记录包名拼错或该包只有 Config 模式而你用了 MODULE核对包名大小写去掉 MODULE 关键字查了目录但没找到文件目录层级不对Config 文件不在预期位置用Pkg_DIR直接指定找到版本不符系统里有多个版本用Pkg_ROOT或Pkg_DIR精确指定找到但链接报 undefined用的是变量写法漏掉了传递依赖改用导入目标写法注意包名的大小写是敏感的find_package(OpenCV)和find_package(opencv)在某些平台上结果完全不同前者找OpenCVConfig.cmake后者找opencv-config.cmake。写错一个字母排查半天。3.4 别忽略环境准备这一环很多找不到包的问题根子其实在环境本身。项目开始前先确认 CMake 版本够用cmake --version看一眼像--debug-find是 3.23 之后才有的Pkg_ROOT是 3.12 引入的find_package的版本区间写法要 3.19。团队协作时最好在 CMakeLists 顶部用cmake_minimum_required明确最低版本避免有人用老版本跑出来一堆奇怪行为。另外提一句如果你是从某些集成开发环境自带的构建流程转过来的习惯可能是勾选配置项然后一键编译。换成 CMake 之后配置阶段和构建阶段是分开的find_package发生在配置阶段配置阶段的报错和编译阶段的报错要分开看别混在一起排查。4. 自己动手把项目导出成别人能 find 的包4.1 install(EXPORT) 生成 Config 文件前面讲的都是用别人的包换个角色如果你想让自己写的库能被同事find_package需要做什么核心是两个命令install(TARGETS ... EXPORT ...)和install(EXPORT ...)。install(TARGETS mylib EXPORT MyLibTargets ARCHIVE DESTINATION lib LIBRARY DESTINATION lib RUNTIME DESTINATION bin INCLUDES DESTINATION include ) install(EXPORT MyLibTargets NAMESPACE MyLib:: FILE MyLibTargets.cmake DESTINATION lib/cmake/MyLib )EXPORT关键字把目标登记到一个导出集合里install(EXPORT)在安装时把这个集合生成成一系列.cmake文件放在lib/cmake/MyLib目录下。NAMESPACE会给所有导出的目标加上前缀这样使用者看到的就是MyLib::mylib这种形式既清晰又能避免和别的库重名。不过install(EXPORT)单独用有个明显短板它不管依赖。如果mylib依赖了Threads生成的文件里不会自动帮你找Threads使用者链接时会报缺符号。正确做法是手写一个模板文件用configure_package_config_file处理。# MyLibConfig.cmake.in PACKAGE_INIT include(CMakeFindDependencyMacro) find_dependency(Threads) include(${CMAKE_CURRENT_LIST_DIR}/MyLibTargets.cmake) check_required_components(MyLib)然后在 CMakeLists.txt 里这样写include(CMakePackageConfigHelpers) configure_package_config_file( ${CMAKE_CURRENT_SOURCE_DIR}/MyLibConfig.cmake.in ${CMAKE_CURRENT_BINARY_DIR}/MyLibConfig.cmake INSTALL_DESTINATION lib/cmake/MyLib ) write_basic_package_version_file( ${CMAKE_CURRENT_BINARY_DIR}/MyLibConfigVersion.cmake VERSION ${PROJECT_VERSION} COMPATIBILITY SameMajorVersion ) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/MyLibConfig.cmake ${CMAKE_CURRENT_BINARY_DIR}/MyLibConfigVersion.cmake DESTINATION lib/cmake/MyLib )这套组合下来使用者就能写find_package(MyLib 1.0 REQUIRED)并且直接链接MyLib::mylib。PACKAGE_INIT会被替换成一段处理相对路径的代码保证包被移动到别的位置后还能正常定位。4.2 导入目标的属性该怎么写导出目标能不能用得舒服关键在INTERFACE_INCLUDE_DIRECTORIES这个属性。它决定了使用者的编译器去哪找你的头文件。写的时候要区分构建时和安装后两种场景。target_include_directories(mylib PUBLIC $BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include $INSTALL_INTERFACE:include )BUILD_INTERFACE里的路径只在当前项目内构建时生效INSTALL_INTERFACE里的路径会被写进导出的 Config 文件相对于安装前缀解析。很多人写导出的时候忘了加生成器表达式直接把源码目录写进去结果别人安装后使用时指向一个根本不存在的路径报出找不到头文件的错误。依赖关系也要用PUBLIC、PRIVATE、INTERFACE分清楚。PUBLIC表示既用于自己编译也传递给使用者PRIVATE表示只自己用INTERFACE表示自己不用但使用者要用。分错了后果很直接本来是PRIVATE的依赖被写成PUBLIC会导致使用者的编译命令里多出一堆无关的头文件路径反过来写成PRIVATE使用者链接时缺依赖报undefined reference。另外COMPATIBILITY参数决定版本校验的严格程度。AnyNewerVersion表示只要找到的版本比要求的新就通过SameMajorVersion表示主版本必须一致ExactVersion要求完全一致。对外发布的库我一般用SameMajorVersion因为主版本变化通常意味着不兼容让使用者早点发现问题比运行时报错强。4.3 交叉编译场景下的特殊处理交叉编译时find_package的行为会变得微妙因为它默认会去主机系统的路径里找包而不是目标平台的。这时候需要在工具链文件里把CMAKE_FIND_ROOT_PATH相关变量配置好。set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g) set(CMAKE_FIND_ROOT_PATH /opt/sysroot) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)MODE_PROGRAM设成NEVER是故意的因为交叉编译时需要的编译工具、代码生成器比如 Protobuf 的 protoc本身要在主机上运行不能从目标平台的 sysroot 里找。而LIBRARY、INCLUDE、PACKAGE设成ONLY确保库文件和 Config 文件都从 sysroot 里取避免误用主机上的库导致链接错误。这套配置踩过一次印象很深的坑某个包在主机的/usr/lib下也有一份交叉编译时 CMake 优先找到了主机版本配置阶段一切正常链接阶段却报出一堆架构不匹配的符号错误。加上MODE_LIBRARY ONLY之后问题消失。所以交叉编译项目一定要把工具链文件写规范别依赖默认行为。5. 常见报错速查与避坑清单5.1 高频报错对照表报错信息关键词根本原因解决方案Could not find a package configuration fileConfig 文件不在搜索路径内指定Pkg_DIR或用CMAKE_PREFIX_PATHFound version 3.2 but required is at least 4.5系统里有旧版本被优先找到用Pkg_ROOT精确指向新版本Target xxx links to target yyy but the target was not found传递依赖没被找到用find_dependency补上或手动 find 那个依赖undefined reference to ...链接了库但缺传递依赖或库顺序不对改用导入目标写法让 CMake 处理顺序Imported target includes non-existent path导出的目标里路径写错通常缺生成器表达式用BUILD_INTERFACE/INSTALL_INTERFACE分开写The current CMakeCache.txt is different than the one used to generate缓存里的路径与实际不符通常是换过环境删除构建目录重新配置这张表覆盖了我日常遇到的绝大多数情况。其中最后一条特别值得说它通常出现在你切换了分支、换了编译器、或者从别的机器拷贝了构建目录之后。CMake 的缓存记录了大量绝对路径环境一变就失效。我的习惯是给每个构建配置建单独的目录比如build-debug、build-release从不复用也不把 build 目录提交到版本库。5.2 Debug 与 Release 混用这个坑动态库在 Windows 上有 debug 和 release 两套版本它们的 CRT 不兼容混用会在链接期报出一堆LNK2038或者运行期崩溃。find_package在 Config 模式下会同时记录两个版本的路径CMake 根据CMAKE_BUILD_TYPE自动选。问题出在有些库的 Config 文件只记录了一个版本或者你手动传了-DCMAKE_BUILD_TYPEDebug但库只有 release 版。处理方式是显式配置映射关系set(CMAKE_MAP_IMPORTED_CONFIG_DEBUG Release) set(CMAKE_MAP_IMPORTED_CONFIG_RELWITHDEBINFO Release)这两行的意思是当我在 Debug 模式下构建时如果导入目标没有 Debug 配置就用 Release 版本顶上。这在 Linux 上问题不大但在跨平台项目里能避免很多麻烦。另外find_package的查找结果会被缓存如果你先配置了 Release 再切 Debug某些变量可能还是旧值。稳妥做法是切换构建类型时重新生成构建目录别指望 CMake 自动更新所有缓存变量。注意CMAKE_BUILD_TYPE是单配置生成器Makefile、Ninja才用的变量多配置生成器Visual Studio、Xcode下应该用--config参数指定。混用会导致构建类型判断出错。5.3 那些文档里不会写的实操心得第一条心得先跑通再优化。刚接手一个项目或者引入新依赖时别一上来就追求脚本写得多优雅先用最直白的方式确认能找到包、能编译通过。能跑通之后再慢慢把变量写法替换成导入目标写法把硬编码路径换成搜索提示。我见过太多人一开始就纠结变量写法和目标写法哪个更好结果连包都没找着。第二条心得给依赖加一层自己的封装。项目里的第三方依赖如果超过三四个建议在cmake/目录下写一层薄的封装模块统一处理找不到时装哪个版本是否需要调试输出不同平台的路径差异。这样主 CMakeLists 里全是include(MyDeps)清爽不说换库的时候只改一个文件。第三条心得把查找结果缓存进日志。在 CI 里配置阶段加上set(CMAKE_FIND_DEBUG_MODE ON)并把输出存成文件一旦构建失败回溯起来特别快。本地开发时不用一直开着太吵。第四条心得别迷信REQUIRED。项目初期用REQUIRED能快速暴露问题但在发布给终端用户的脚本里对可选依赖用QUIET加if(Foo_FOUND)分支处理能让构建在依赖不全的环境里也能降级跑起来。find_package(ZLIB QUIET) if(ZLIB_FOUND) target_link_libraries(app PRIVATE ZLIB::ZLIB) target_compile_definitions(app PRIVATE HAVE_ZLIB1) else() message(STATUS zlib 未找到将禁用压缩功能) endif()这段代码展示了条件依赖的标准写法找不到就把功能关掉同时通过编译宏告知源码而不是直接中断整个构建。要判断 CMake 缓存里的旧值在捣乱最直接的办法是删掉构建目录重新配置一遍比任何排查手段都快。我在多个项目里反复验证下来find_package真正难的不是语法而是对搜索机制的心理模型。脑子里有一张CMake 会去哪些地方找、找到后留下什么变量的地图绝大部分问题当场就能定位。剩下那一小部分交给--debug-find打印出来的路径日志也基本能水落石出。