Prefer HINTS to PATHS in cmake find modules #6218
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the list of paths searched by CMake, the content of the HINTS arg appears early on, while the content of PATHS is down the list. In particular, between HINTS and PATHS in that list there are - system paths - cmake package registry These can cause system installation of a tpl or previous installation of a tpl to be picked up instead of the passed PATHS arg
jgfouca
approved these changes
Feb 7, 2024
|
|
@jgfouca you can merge this. |
jgfouca
added a commit
that referenced
this pull request
Feb 15, 2024
…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 #6217 [BFB]
|
Merged to next. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For all the cmake
find_XYZutilities, there is a well defined ordered list in which CMake scans paths while searching. In this list, the paths passed via the argumentHINTSappear early on. On the other hand, the paths passed via the argumentPATHSappear quite late. After tryingHINTSand before tryingPATHS, CMake consider other options, among which we have/usrdirectory on linux)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
HINTSit states thatHowever, the fact that
PATHSis scanned after system folders makes its usage more complicated. SinceHINTSandPATHSare 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_PATHto thefind_XYZcalls, 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. UsingHINTS, we can still pick up the system install (leaving HINTS empty).Fixes #6217 .