grpc与CMake中find_package()命令神奇的寻址

Cpp

发布日期: 2024-05-17

更新日期: 2024-05-17

文章字数: 682

阅读时长: 2 分

阅读次数:

概述

问题总是在你意想不到的地方出现。

重启了个电脑怎么就报错了呢

昨天还在用，更新了一下写了个

有毛病

排查过程

长话短说，我一开始以为是谷歌的锅，看了一圈issue还去Stack Overflow上差了发现没人遇到我这个问题，当时我就怀疑是不是版本的问题，然后我把版本号打出来一看20230802（没意识到用的是最新的absl）

在这之后去还去看了absl的abslTargets.cmake，确实是有的，那么其实可以知道不是谷歌的锅，肯定又是和之前protobuf一样的全局变量的问题，但是这次问题就诡异在我没有显示或者隐式的引入过任何absl的库，那么为什么会报错。

确实有

后面还下了最新的absl加入到全局环境变量里面也不行（太神奇了），到后面想到可以看它引用的库地址在哪，一看发现非常神秘的找到了我曾经make过的库，但是这个库和grpc库是同级的。

要不是我版本名字取错了我还真没意识到

直接删掉一试，发现就好了。

尝试修改

通过编译。

终于解决了

那么为什么grpc库会找到同级目录下的其他absl？

原来是你

find_package()查找逻辑

CMAKE先在CMAKE_MODULE_PATH变量对应的路径中查找。如果路径为空，或者路径中查找失败，则在cmake module directory（cmake安装时的Modules目录，比如/usr/local/share/cmake/Modules）查找。

搜索标准的系统环境变量PATH，其中如果是以/bin或者/sbin结尾的，会自动转化为其父目录，发现没有，makeInstall下面有一个bin文件夹，所以会自动转换，在同级文件夹下去找，而不是去子文件夹中寻找（优先级低）。

CMake为该软件包构造了一组可能的安装前缀。在每个前缀下的几个目录中搜索配置文件。下表显示了搜索的目录。每个条目均用于遵循Windows（W），UNIX（U）或Apple（A）约定的安装树：

<prefix>/                                                       (W)
<prefix>/(cmake|CMake)/                                         (W)
<prefix>/<name>*/                                               (W)
<prefix>/<name>*/(cmake|CMake)/                                 (W)
<prefix>/(lib/<arch>|lib*|share)/cmake/<name>*/                 (U)
<prefix>/(lib/<arch>|lib*|share)/<name>*/                       (U)
<prefix>/(lib/<arch>|lib*|share)/<name>*/(cmake|CMake)/         (U)
<prefix>/<name>*/(lib/<arch>|lib*|share)/cmake/<name>*/         (W/U)
<prefix>/<name>*/(lib/<arch>|lib*|share)/<name>*/               (W/U)
<prefix>/<name>*/(lib/<arch>|lib*|share)/<name>*/(cmake|CMake)/ (W/U)