考虑下面的简单CMake脚本，试图找到虚构的theheader.h C头文件。据我所知，这是在FindXXX.cmake模块中找到库的include目录的典型方法。
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目录：
PATH="/home/cschreib/someapp/bin:$PATH"
事实证明，目录/home/cschreib/someapp/include存在，并包含名为theheader.h的文件。此标头仅在本地用于构建someapp，它从未打算被其他程序使用*。
在CMake 3.3之前，CMake从未发现过这个自定义位置。但是，从版本3.3开始，CMake尝试变得聪明，并将bin替换include替换$PATH中的所有目录。因此，CMake 3.3（及更高版本）确实在此自定义目录中找到theheader.h。因为这绝不是预期的，所以这会导致各种麻烦，包括标头和共享对象版本之间的不匹配。
我知道我可以告诉CMake不要使用$PATH中的NO_SYSTEM_ENVIRONMENT_PATH选项查看find_path，但我正在寻找更通用的解决方案。实际上，任何图书馆都可能出现这个问题。我可以复制我需要的所有FindXXX.cmake模块并系统地添加NO_SYSTEM_ENVIRONMENT_PATH选项，但我宁愿避免这种情况。
我可以使用全局开关来关闭这个不需要的功能吗？还是其他一些出路？
*：在有人发表评论之前。我知道这不是好习惯。我也知道，在我的社区，人们往往不关心好的和坏的做法，这种情况很常见。由于我不打算更改社区，因此我希望我的CMake脚本能够抵御不良做法。
答案 0 :(得分：3)
对于使用CMake版本3.6的非Windows平台，此行为再次被删除。
如果您遇到此问题，只需更新最新的CMake版本。请参见版本3.6发行说明Deprecated and Removed Features：
}，find_library()和find_path()命令不再搜索从非Windows平台上的find_file()环境变量派生的安装前缀。在CMake 3.3中添加了此行为以支持Windows主机，但在UNIX主机上已证明存在问题。在PATH中仅为其工具保留一些PATH目录的用户不一定需要搜索任何支持<prefix>/bin目录。可以将<prefix>/lib环境变量设置为： - 要搜索的前缀列表。
答案 1 :(得分：1)
据我所知，CMake 3.5中不存在这样的开关。我不会尝试解决这个问题，因为即使你对CMake进行了破解，这仍然可能会使编译器或用户感到困惑。
标题来自哪里？你能问一个项目改变标题吗？通常项目不想与其他图书馆发生冲突，并试图解决这些问题。