[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