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                                                                                                                                                     
        )

我来自make背景，所以我会使用像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_*命令没有这样的先决条件。他们只是试图找到文件系统的文件或目录。这就是它们在某种程度上使它们成为最强大的命令的原因，因为你总是可以接受用户提供的提示，在哪里找到文件（你的示例代码中的人不做btw，所以很遗憾在他们身上）然后发现可以发挥它的魔力。但它也是最不方便的，因为在实践中使用它很容易搞乱和乏味。

所以请记住，CMake的主要目标是移植。不要回避平台提供的任何机制来使配置更方便，但也不要锁定不那么幸运的人，并且必须在没有这些机制的平台上工作。

你什么时候使用find_path？

1 个答案: