问题描述
我在使用模块的HPC系统上使用CMake.这些模块通常设置LIBRARY_PATH和CPATH，因此一个模块可以简单地包含头文件并链接到库，而无需其他-L或-I.
I'm using CMake on a HPC system that uses modules. Those modules usually set LIBRARY_PATH and CPATH so one can simply include headers and link against libraries without additional -L or -I.
但是，当使用CMake时，那些必须由CMake找到的库.我希望CMake自动考虑LIBRARY_PATH和CPATH并将其捕获在例如CMAKE_SYSTEM_LIBRARY_PATH和CMAKE_SYSTEM_INCLUDE_PATH，但不是.
However when using CMake those libraries must be found by CMake. I would expect, that LIBRARY_PATH and CPATH were automatically considered by CMake and captured in e.g. CMAKE_SYSTEM_LIBRARY_PATH and CMAKE_SYSTEM_INCLUDE_PATH but they are not.
有什么理由可以做到(不)吗?
Is there any reasoning why this was (not) done?
将LIBRARY_PATH附加到CMAKE_SYSTEM_LIBRARY_PATH并将CPATH附加到CMAKE_SYSTEM_INCLUDE_PATH是不是一个好主意(现在是手动，后来由CMake自动添加)?
Wouldn't it be a good idea (for now manually, later automatically by CMake) to append LIBRARY_PATH to CMAKE_SYSTEM_LIBRARY_PATH and CPATH to CMAKE_SYSTEM_INCLUDE_PATH?
推荐答案
将LIBRARY_PATH附加到CMAKE_SYSTEM_LIBRARY_PATH并将CPATH附加到CMAKE_SYSTEM_INCLUDE_PATH是不是一个好主意(现在是手动，后来由CMake自动添加)?
Wouldn't it be a good idea (for now manually, later automatically by CMake) to append LIBRARY_PATH to CMAKE_SYSTEM_LIBRARY_PATH and CPATH to CMAKE_SYSTEM_INCLUDE_PATH?
还有另一种观点，认为您的构建依赖于环境变量会导致构建不可靠. 摘自GNU Make手册:
There is another view that having your build depend on environment variables results in unreliable builds. From GNU Make manual:
这篇关于为什么CMake不尊重LIBRARY_PATH和CPATH的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！