[CMake] FindXXX.cmake specification inconsistency

[Alan W. Irwin]

On 2007-04-22 02:14+0200 r.koebler at yahoo.de wrote:

>>> should XXX_INCLUDE_DIRS and XXX_LIBRARIES *really* be excluded from
>>> the (user-configurabe) cache?
>>> (I don't think so, because then it's not possible for the user to
>>>  configure these paths...)
>>
>> The preferred method is for the user to set CMAKE_INCLUDE_PATH and
>> CMAKE_LIBRARY_PATH appropriately, see
>> http://www.cmake.org/Wiki/CMake_Useful_Variables. The advantage of this
>> approach is it greatly reduces the number of different variables that the
>> user has to worry about.
> ok, so XXX_INCLUDE_DIRS and XXX_LIBRARIES should be in the cache, but
> hidden/INTERNAL. right ?

No, they are just set with an ordinary (without CACHE option) SET command
in the vast majority of Find*.cmake module cases.

On Linux, I verified this using

grep -A 1 -i libraries $PREFIX/share/cmake-2.4/Modules/Find*.cmake \
|grep -A 1 -i set |less

grep -A 1 -i include_dirs $PREFIX/share/cmake-2.4/Modules/Find*.cmake \
|grep -A 1 -i set |less

where $PREFIX was my cmake install prefix.  The first search found two
instances out of many where the CACHE was used and the second search found
none out of many.  So it appears in at least these cases that (except for
those two instances) the directions in readme.txt are being followed.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________