[cmake-developers] Find module problems

Bill Hoffman bill.hoffman at kitware.com
Fri Mar 28 19:25:50 EDT 2008


Alexander Neundorf wrote:
> On Friday 28 March 2008, Bill Hoffman wrote:
>> So, a number of modules have been updated and variable names have been
>> changed.  To maintain backwards compatibility with the old stuff a set
>> has been used to set the new variable.  The problem is many automatic
>> builds are setup to pre-load the cache or specify a value on the command
> 
> Are the automatic builds the only problem ?
> Would it be an option to just adapt the preload files ?
> 
> This was really an easy way to keep backwards compatiblity for normal uses. 
> 
No, it just seems like an easy way, in fact it is a really bad way. 
Here is why...  If you have scripts that either create a CMakeCache.txt, 
or use -DFOO=/some/location, then it most likely means that you have 
stuff installed somewhere where you think cmake won't find it.    CMake 
itself built incorrectly when I went to make the 2.6 beta because 
FindCurses has one of these changes.  ParaView has lots of stuff like 
this because it uses very odd locations for MPI (vendor specific MPI 
stuff). All of those types of builds get broken by this type of thing. 
  The only time this works is when CMake finds the libraries.  However, 
when people create a cache or use the command line -D, most of the time 
the library or header file is in a place that is not going to be found.

One approach is to keep the old cache variables, and put those values 
into the new non-cached variable.  So, if you had:
FOO_LIBRARY CACHE
and you want
FOO_LIBRARIES non-cache
You do this:
FIND_LIBRARY(FOO_LIBRARY foo)
SET(FOO_LIBRARIES ${FOO_LIBRARY})

This is now fully backwards compatible, and has the new non cache variable.

-Bill



More information about the cmake-developers mailing list