c++ - 什么时候使用 find_path？

Question

我正在对某人的代码进行逆向工程，我在 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                                                                                                                                                     
        )

我有制作背景，所以我会使用像 LDFLAGS=$(shell pkg-config --cflags --libs openssl 这样的东西，但我永远不知道包含了什么头文件。

了解每个头文件似乎不切实际/不可行，例如，链接 opencv 和 cuda 库的大型 dlib 项目，所以我的问题是:

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

Answer 1

CMake 需要支持 pkg-config 不可用的平台。

您是正确的，查找机制有些原始。这就是为什么 CMake 还提供了 more sophisticated options like config-file packages or even pkg-config support .所有这些方法的问题在于它们需要某种外部支持之王。包配置脚本必须由您尝试查找的依赖项提供，并且 pkg-config 必须在您尝试构建的平台上可用并正确配置。

各种 find_* 命令没有这样的先决条件。他们只是试图在文件系统中找到一个文件或目录。这就是使它们在某种程度上成为最强大命令的原因，因为您始终可以接受用户提供的在哪里可以找到文件的提示(您的示例代码中的人没有顺便说一句，真可惜在他们身上)然后找到可以发挥它的魔力。但它也是最不方便的，因为它很容易搞砸并且在实践中使用起来很乏味。

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