[CMake] FIND_PATH() search custom path first

Jakub Zakrzewski jzakrzewski at e2e.ch
Tue Oct 28 08:57:54 EDT 2014



From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of George
Sent: Dienstag, 28. Oktober 2014 13:42
To: cmake at cmake.org
Subject: Re: [CMake] FIND_PATH() search custom path first



On 28 October 2014 09:34, Jakub Zakrzewski <jzakrzewski at e2e.ch<mailto:jzakrzewski at e2e.ch>> wrote:
> I have a situation where I need to prefer a custom-build of a library over any system-installed versions. I understand that the paths in the HINTS variable will be searched before the > system ones, but the documentation discourages its use with hard-coded paths.
> If I do hard-code a HINTed path, what problems would that cause?
It's "just" a best practise. Someone smarter has come up with the right order and it looks sensible to me. I'd suggest, that you do your search in two steps:

find_path( MY_FILE
  NAMES "my_file.txt"
  PATHS
  "/the/file/is/here"
"/or/maybe/here"
  NO_DEFAULT_PATH
  NO_CMAKE_ENVIRONMENT_PATH
  NO_CMAKE_PATH
  NO_SYSTEM_ENVIRONMENT_PATH
  NO_CMAKE_SYSTEM_PATH
  NO_CMAKE_FIND_ROOT_PATH
)

find_path( MY_FILE
  NAMES "my_file.txt"
)

If the file is found wit the first call, then CMake won't try to find it again. Otherwise it'll proceed with standard search (second call).

--
Gruesse,
Jakub


I would very much like to know the actual technical reason behind the practice. On the surface, it appears there is no reason for having two searches if HINTS works in the way that it says.  This posting

http://mail.kde.org/pipermail/kde-buildsystem/2008-June/004762.html
appears to indicate that HINTS was created for exactly the purpose I need:
HINTS ${SOMEPLACE_I_WANT_TO_LOOK_FIRST}
George


As I said - it's best practise. HINTS *should* be computed by system introspection and are prefferred over system paths (but not CMake paths). If you know in advance, where your files are, you should probably use one of CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH, CMAKE_FRAMEWORK_PATH and let CMake find your files by itself.

--
Gruesse,
Jakub


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141028/0606f436/attachment.html>


More information about the CMake mailing list