From: Werner Smekal <smekal@ia...>  20090227 21:13:37

Hi Alan, > > 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. Thanks for the explanations. I changed the code now to: check_symbol_exists(finite "math.h" HAVE_FINITE) if(NOT HAVE_FINITE) check_function_exists(finite HAVE_FINITE2) if(HAVE_FINITE2) set(HAVE_FINITE ${HAVE_FINITE2} CACHE INTERNAL "Have function finite") else(HAVE_FINITE2) check_symbol_exists(_finite "math.h" _HAVE_FINITE) if(NOT _HAVE_FINITE) check_function_exists(_finite _HAVE_FINITE2) if(_HAVE_FINITE2) set(_HAVE_FINITE ${_HAVE_FINITE2} CACHE INTERNAL "Have function _finite") set(HAVE_FINITE ${_HAVE_FINITE} CACHE INTERNAL "Have function _finite") endif(_HAVE_FINITE2) set(_HAVE_FINITE2 "" CACHE INTERNAL "Have function _finite") endif(NOT _HAVE_FINITE) endif(HAVE_FINITE2) set(HAVE_FINITE2 "" CACHE INTERNAL "Have function finite") endif(NOT HAVE_FINITE) This works now, and using Visual C++ doesn't always lead to reconfiguration. And if cmake is run again, the variables are taken correctly from the cache. What I don't understand is, that check_symbol_exists(finite "math.h" HAVE_FINITE) if(NOT HAVE_FINITE) check_function_exists(finite HAVE_FINITE) endif(NOT HAVE_FINITE) Doesn't work. check_function_exists is called, but IF("${VARIABLE}" MATCHES "^${VARIABLE}$") in CheckFunctionsExists.cmake/CheckFunctionsExists.cmake is true for check_symbol_exists and false for check_function_exists???? HAVE_FINITE is both times "".I also don't understand "${VARIABLE}" MATCHES "^${VARIABLE}$"  I was playing around with a regex checker and no matter what I did ("test" matches "^test$", "" matches "^$", etc.) this statement was always true. Why it is false for check_function_exists I don't get. This would make the logic a lot easier .... Regards, Werner > > 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 > __________________________  Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 810 A1040 Wien Austria DVRNr: 0005886 email: smekal@... web: http://www.iap.tuwien.ac.at/~smekal phone: +43(0)15880113463 (office) +43(0)15880113469 (laboratory) fax: +43(0)15880113499 