阻止CMake查找PATH的库和包含 [英] Prevent CMake from looking into PATH for libraries and includes

查看:169
本文介绍了阻止CMake查找PATH的库和包含的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

考虑下面的简单CMake脚本试图找到一个虚构的 theheader.h C头文件。据我所知,这是找到 FindXXX.cmake 模块中库的include目录的典型方法。

Consider the simple CMake script below trying to find a fictional theheader.h C header file. As far as I know, this is the typical way to locate the include directory of a library in the FindXXX.cmake modules.

cmake_minimum_required(VERSION 2.6)
project(test)

find_path(
    TEST_INCLUDES
    NAMES "theheader.h"
)

message(STATUS "TEST_INCLUDES: ${TEST_INCLUDES}")

现在假设,以一种与这个CMake脚本无关的方式,我编辑了我的 PATH 环境变量(我运行Linux)包含自定义 bin 目录:

Now assume that, in a way unrelated to this CMake script, I have edited my PATH environment variable (I'm running Linux) to contain a custom bin directory:

PATH="/home/cschreib/someapp/bin:$PATH"

结果是,目录 / home / cschreib / someapp / include 存在,并包含名为 theheader.h 的文件。这个头部仅用于本地构建 someapp ,它从来不是被其他程序使用*。

Turns out, the directory /home/cschreib/someapp/include exists, and contains a file named theheader.h. This header was only used locally to build someapp, it was never meant to be used by other programs*.

在CMake 3.3之前,这个自定义位置从来没有被CMake发现。但是,从版本3.3开始,CMake试图聪明,并替换 bin include $ c> $ PATH 。因此,CMake 3.3(及以上)在此自定义目录中找到 theheader.h 。因为这是从来没有打算,这是造成各种麻烦,包括头和共享对象版本之间的不匹配。

Before CMake 3.3, this custom location was never found by CMake. However, starting with version 3.3, CMake tries to be smart and substitutes bin for include for all directories in $PATH. Therefore, CMake 3.3 (and above) does find theheader.h in this custom directory. Because this was never intended, this is causing all sorts of trouble, including a mismatch between headers and shared objects versions.

我知道我可以告诉CMake不要查看<使用 find_path 中的 NO_SYSTEM_ENVIRONMENT_PATH 选项创建code $ 我正在寻找一个更通用的解决方案这个问题。事实上,这个问题可能发生在任何库。我可以做一个所有FindXXX.cmake模块的副本,并系统地添加 NO_SYSTEM_ENVIRONMENT_PATH 选项,但我宁愿避免这样。

I know I can tell CMake not to look in $PATH by using the NO_SYSTEM_ENVIRONMENT_PATH option in find_path, but I am looking for a more generic solution to this issue. Indeed, this problem can happen for any library. I could make a copy of all the FindXXX.cmake modules I need and systematically add the NO_SYSTEM_ENVIRONMENT_PATH option, but I would rather avoid this.

有没有全局开关我可以用来关闭这个不需要的功能?还是有其他出路?

Is there a global switch I could use to turn off this unwanted feature? Or some other way out?

*:在有人评论之前。我知道这不是好的做法。我也知道,在我的社会,人们往往不太在乎好的和坏的做法,这种情况是非常普遍的。因为我不会改变社区,所以我想要我的CMake脚本对不良做法是强大的。

*: Before someone comments on this. I am aware this is not good practice. I am also aware that, in my community, people tend not to care much about good and bad practices, and this situation is very common. Since I am not going to change the community, I want my CMake scripts to be robust against bad practices.

推荐答案

再次为非Windows平台删除与CMake版本3.6。

This behavior was removed again for non-Windows platform with CMake version 3.6.

如果你碰到这个问题,只要更新最新的CMake版本。请参见版本3.6发行说明弃用和已删除的功能

If you run into this problem just update the the latest CMake version. See version 3.6 release notes Deprecated and Removed Features:


find_library() find_path() find_file()命令不再搜索从 PATH 环境变量在非Windows平台上。在CMake 3.3中添加了此行为以支持Windows主机,但在UNIX主机上已证明有问题。在PATH中为它们的工具保留一些< prefix> / bin 目录的用户不一定需要任何支持的< prefix> / lib 搜索的目录。可以用要搜索的前缀列表设置 CMAKE_PREFIX_PATH 环境变量。

The find_library(), find_path(), and find_file() commands no longer search in installation prefixes derived from the PATH environment variable on non-Windows platforms. This behavior was added in CMake 3.3 to support Windows hosts but has proven problematic on UNIX hosts. Users that keep some <prefix>/bin directories in the PATH just for their tools do not necessarily want any supporting <prefix>/lib directories searched. One may set the CMAKE_PREFIX_PATH environment variable with a ;-list of prefixes that are to be searched.

这篇关于阻止CMake查找PATH的库和包含的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆