Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'bartgol/cmake/use-hints-instead-of-paths' into master (PR
E3SM-Project#6218) Prefer HINTS to PATHS in cmake find modules For all the cmake find_XYZ utilities, there is a well defined ordered list in which CMake scans paths while searching. In this list, the paths passed via the argument HINTS appear early on. On the other hand, the paths passed via the argument PATHS appear quite late. After trying HINTS and before trying PATHS, CMake consider other options, among which we have: * system paths (e.g., /usr directory on linux) * cmake package registry (this is only for find_package, but can be quite annoying and hard to find, as we experienced with EKAT) CMake states that HINTS and PATHS should be used for different reasons. In particular, regarding HINTS it states that: These should be paths computed by system introspection, such as a hint provided by the location of another item already found. Hard-coded guesses should be specified with the PATHS option. However, the fact that PATHS is scanned after system folders makes its usage more complicated. Since HINTS and PATHS are treated in the same way (meaning, CMake grabs the paths contained in them, and just scan them), from the practical point of view, the difference between the two is just the fact that one is considered much earlier than the other. The alternative would have been to add NO_SYSTEM_PATH to the find_XYZ calls, but it comes with a drawback: if on some testing machine (a shared workstation, perhaps) we do have a valid installation of a tpl in the system paths, we would not pick it up. Using HINTS, we can still pick up the system install (leaving HINTS empty). Fixes E3SM-Project#6217 [BFB]
- Loading branch information