[CMake] New FIND_* stuff checked into CVS
Alexander Neundorf
a.neundorf-work at gmx.net
Mon Mar 6 07:13:04 EST 2006
> An: cmake at cmake.org
>
> I have checked in a change to the way that the FIND_* commands work.
> It should be backwards compatible with the old commands, but allow for
> more control over search paths and how things are searched for.
> All 4 commands now use the same code to parse the arguments, so they
> are now consistent. They can all disable the 4 external search paths
> used. Also, they have a PATH_SUFFIXES argument that allows for the
> specification of
> a directory name that can be added into all search paths. For example,
> if you wanted to find a header like qt.h but this is always found in
> qt/qt.h, you could do this:
>
> FIND_PATH(QT_INCLUDE NAMES qt.h PATH_SUFFIXES qt)
Last weekend I was at Linuxtag Chemnitz (where I held a talk about cmake,
more about this later) and there was an additional idea:
CMAKE_INSTALL_PREFIX could/should also be checked, i.e. for headers
${CMAKE_INSTALL_PREFIX}/include, for libs ${CMAKE_INSTALL_PREFIX}/lib and
${CMAKE_INSTALL_PREFIX}/bin for executables.
Does this make sense for you ?
(e.g. for KDE this makes a lot of sense, if you compile a kde module,
e.g. kdenetwork, you will want to install it to the same directory as
kdelibs, so this will also be the directory where a lot of stuff will be
found.)
Should/could this be added to the FIND_XXX() commands ?
Should/could this be added to the appropriate FindFOO.cmake files ?
Should/could thios be done by adding this path to the appropriate
CMAKE_XXX_PATH variable ?
Bye
Alex
--
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
More information about the CMake
mailing list