cmake: How to use check_something() macros with non-standard locations, Was: Re: invitation: try compiling kdelibs using cmake

[Brad King]

Alexander Neundorf wrote:
> On Saturday 28 January 2006 00:26, Brad King wrote:
>>1.) Paths listed in the CMAKE_INCLUDE_PATH variable in the cache.
>>2.) Paths listed in the CMAKE_INCLUDE_PATH environment variable.
>>3.) Paths listed in the INCLUDE environment variable.
>>4.) Paths listed in the call to the FIND_PATH command.
> 
> These variables are used for the find_xxx() commands, right ?

Yes.

> Is there a way to set additional directories for the check_something_exists() 
> macros ? (except of setting a special variable for each of the checks, more 
> like a global variable which will be used for everything).

The "special variable" for each check is leftover from when the macros 
were first implemented because we did not support a variable number of 
arguments to macros.  Setting a special variable before invoking the 
macro and clearing it afterwards was the work-around way to fake 
variable arguments.

The built-in Check* macros that come with CMake are definately a bit out 
of date.  They work for a few simple tests and are sufficient for many 
small projects.  For big projects with alot of tests, people have 
generally created custom macros to do TRY_COMPILE tests:

http://www.vtk.org/cgi-bin/viewcvs.cgi/Utilities/kwsys/kwsysPlatformCxxTests.cmake?root=VTK&view=markup
http://cvs.sourceforge.net/viewcvs.py/vxl/vxl/config/cmake/config/vxl_config_macros.cmake?view=markup

There is room for a new set of Check* macros to be created that have a 
modernized interface.  We could even create a new command to help do 
checks only once without the big mess of IF tests present in the current 
macros.  Open a CMake feature request and we can continue the discussion 
there.

Meanwhile I suggest you just copy the Check* macros into KDE and edit 
them to have whatever interface you want.  That will serve as a good 
testing ground for evaluating new interfaces.

-Brad