C++ 您什么时候使用find_path？

我正在逆向工程某人的代码，我在CMake文件中遇到了这样一行代码

FIND_PATH(OPENSSL_INCLUDE_DIR openssl/ssl.h
        /usr/local/opt/openssl/include
        /usr/opt/openssl/include
        /usr/local/include/openssl
        /usr/include/openssl
        /usr/local/include
        /usr/include
        )

INCLUDE_DIRECTORIES(${OPENSSL_INCLUDE_DIR})

FIND_LIBRARY(LIB_CRYPTO crypto PATHS
        /usr/local/opt/openssl/lib
        /usr/opt/openssl/lib
        /usr/local/lib
        /usr/local/openssl/lib
        /usr/lib
        /usr/lib/openssl                                                                                                                                                     
        )

我来自make背景，所以我会使用类似于

LDFLAGS=$（shell pkg config--cflags--libs openssl

的东西，但我永远不知道包含了什么头文件

了解包含在链接opencv和cuda库的大型dlib项目中的每个头文件似乎不切实际/不可行，因此我的问题是：

---

您何时/为什么实际按名称引用头文件？

CMake需要支持

pkg config

不可用的平台

您是对的，查找机制有些原始。这就是为什么CMake也提供了。所有这些方法的问题是它们需要一些外部支持。包配置脚本必须由您试图查找的依赖项提供，并且

pkg config

必须在pla上可用并正确配置t您试图构建的表单

各种

find.*

命令没有这样的先决条件。它们只是尝试在文件系统中查找文件或目录。这就是它们在某种程度上成为最强大的命令的原因，因为您总是可以接受用户提供的在何处查找文件的提示（顺便说一句，示例代码中的人没有这样做，所以他们感到羞耻）然后这个发现可以发挥它的魔力。但它也是最不方便的，因为它很容易搞乱，在实践中使用起来也很乏味

---

因此请记住，CMake的主要目标是可移植性。不要回避平台提供的任何机制，以使配置构建更加方便，但也不要将那些不幸的人拒之门外，他们必须在那些机制不可用的平台上工作。

第一个示例是搜索包含通过查找预期存在的单个标头来创建整个库的文件夹。我在为其创建查找程序的其他库中也做了相同的操作。@drescherjm这似乎是一个穷人的pkg配置。Cmake没有更好的方法包含标头的位置吗？这是关于查找标头的位置。我没有pkg co的经验nfig，因此我无法在这方面比较两者。这也是针对模块编写器的。如果您没有编写模块/查找器，则不需要使用它。大多数CMake用户永远不需要使用find_path（）。相反，他们将使用find_package（）我认为Cmake函数

find_package（）

相当于

pkg config

事实上，当有人为您编写“find*”模块时，Cmake工作得最好：-）他们有相当多的Cmake安装了：使用

find_包（openssl）

（请参阅）查找OpenSSL和OpenSSL加密库。此方法是cmake的一部分，不调用第三方工具，这是跨平台的优势。