From: Alan W. Irwin <irwin@be...>  20090226 23:28:58

On 20090226 21:20+0100 Werner Smekal wrote: > Hi Alan and Andrew, > > in plplot.cmake we determine if finite/isnan/isinf or > _finite/_isnan/_isinf is available with such code > > check_symbol_exists(finite "math.h" HAVE_FINITE) > if(NOT HAVE_FINITE) > check_function_exists(finite HAVE_FINITE2) > endif(NOT HAVE_FINITE) > set(HAVE_FINITE ${HAVE_FINITE2}) > if(NOT HAVE_FINITE) > check_symbol_exists(_finite "math.h" _HAVE_FINITE) > if(NOT _HAVE_FINITE) > check_function_exists(_finite _HAVE_FINITE2) > endif(NOT _HAVE_FINITE) > set(_HAVE_FINITE ${_HAVE_FINITE2}) > set(HAVE_FINITE ${_HAVE_FINITE} CACHE INTERNAL "Have function _finite") > endif(NOT HAVE_FINITE) There are a number of problems in the above logic. (*) HAVE_FINITE, HAVE_FINITE2, _HAVE_FINITE and _HAVE_FINITE2 are all cached as a result of check_symbol_exists and check_function_exists. (See the commands SET(${VARIABLE} 1 CACHE INTERNAL "Have symbol ${SYMBOL}") and SET(${VARIABLE} 1 CACHE INTERNAL "Have function ${FUNCTION}") in CheckSymbolExists.cmake and CheckFunctionExists.cmake). So all further attempts to set those variables should also mention CACHE INTERNAL or else you should use a different name (UNCACHED_HAVE_FINITE ?) for the uncached variables you are setting. (In CMake the same name can refer to separate variables, the cached one and the uncached one.) It's possible the current logic works, but with this reuse of names it gets quite confusing so I would advocate using separate names for variables that mean separate things, and definitely you should not use the same name for both a cached variable and uncached variable. (*) The set(HAVE_FINITE ${HAVE_FINITE2}) assumes check_function_exists(finite HAVE_FINITE2) has been called, but what if the first check_symbol_exists succeeds? Then, that success is ignored, HAVE_FINITE2 is undefined, and then you start looking incorrectly for the _finite symbol or _finite function. Once those two issues are straightened out, I think the logic will work both the first manual time and subsequent automatic times cmake is called. Note, on the second and subsequent times, the cache is used to retrieve values rather than actually doing the checks to determine those values. That is why CMake is so notorious for speed, but it also means you have to be careful of whether variables are cached or not like I advocate above. > Anyway, do you both can help me to solve this problem, since I'm not > sure how to proceed. I would suggest the above changes. Then debug the second and subsequent times cmake is run by putting in lots of message statements to verify all values are being set correctly from the cache. Good luck sorting this out. 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 equationofstate 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). __________________________ Linuxpowered Science __________________________ 