[CMake] FindXXX.cmake specification inconsistency

[Alan W. Irwin]

On 2007-04-22 12:32+0200 r.koebler at yahoo.de wrote:

> hi,
>
>>> 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.
>
>> So it appears in at least these cases that (except for
>> those two instances) the directions in readme.txt are being followed.
> ok, but these packages put XXX_INCLUDE_DIR and XXX_LIBRARY into the
> cache, which I think is even more confusing. (and they often put
> even more (lower-level) variables into the cache [1].)
>
> in detail: many of these packages
> - set XXX_INCLUDE_DIR, and put it into the cache (via FIND_PATH)
> - set XXX_INCLUDE_DIRS to XXX_INCLUDE_DIR (if the library was found),
>                       and don't put it into the cache.
> - set XXX_LIBRARY,     and put it into the cache (via FIND_LIBRARY)
> - set XXX_LIBRARIES    to XXX_LIBRARY     (if the library was found),
>                       and don't put it into the cache.

and that behaviour is exactly consistent with readme.txt.

"The following names should not usually be used in CMakeLists.txt files, but
they may be usefully modified in users' CMake Caches to control stuff.

XXX_LIBRARY [...]
XXX_INCLUDE_DIR [...]

"

Also note this quote:

"For tidiness's sake, try to keep as many options as possible out of the
cache, leaving at least one option which can be used to disable use of the
module, or locate a not-found library (e.g. XXX_ROOT_DIR). For the same
reason, mark most cache options as advanced."

Of course, module writers must deal with lots of cached variables because of
the find_* commands (as you noted above).  But the above quotes show how to
keep those cached variables from cluttering the non-advanced menus and also
give advice to CMakeLists.txt writers about avoiding use of those cached
variables.

I am not a great module guru or anything, but it appears to me that the
readme.txt authors have put a lot of thought into it.  Also, it appears that
the vast majority of modules conform to the readme.txt specifications that
you and I have looked at recently.  So I am largely reassured by these
results.

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
__________________________