[CMake] FIND_PATH() search custom path first

[George]

On 28 October 2014 09:34, Jakub Zakrzewski <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141028/a27930b4/attachment.html>