Re: [CMake] FIND_PATH() search custom path first
Hi George, Jakub,
NO_DEFAULT_PATH
NO_CMAKE_ENVIRONMENT_PATH
NO_CMAKE_PATH
NO_SYSTEM_ENVIRONMENT_PATH
NO_CMAKE_SYSTEM_PATH
The options specified are redundant. NO_DEFAULT_PATH implies the later 4.
If you just specify NO_DEFAULT_PATH then only HINTS and user guess paths
(those specified by the PATH argument) will be checked.
NO_CMAKE_FIND_ROOT_PATH
This is specific to cross compiling, and usually isn't needed unless that's
your situation.
A particularly effective and commonly used pattern is to build up the
options to the find call in a variable. The FindBoost module does this
very thing to restrict it's component search to all the same directory.
The idea is that if you have a specific location that you know your file
should be found in when set, then something like this could work:
set(FOO_FIND_OPTS)
if(FOO_DIR)
set(FOO_FIND_OPTS HINTS ${FOO_DIR} NO_DEFAULT_PATH
NO_CMAKE_FIND_ROOT_PATH)
endif()
find_library(FOO_LIBRARY MyFooLib ${FOO_FIND_OPTS})
This way, if FOO_DIR is set, then it will only look there. However, if
it's not, then FOO_FIND_OPTS is empty and the standard search will happen.
- Chuck
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] FIND_PATH() search custom path first
On 28 October 2014 09:34, Jakub Zakrzewski jzakrzew...@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
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] FIND_PATH() search custom path first
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 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] FIND_PATH() search custom path first
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of George
Sent: Dienstag, 28. Oktober 2014 13:42
To: cmake@cmake.org
Subject: Re: [CMake] FIND_PATH() search custom path first
On 28 October 2014 09:34, Jakub Zakrzewski
jzakrzew...@e2e.chmailto:jzakrzew...@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
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
