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
re-configuration. 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 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
> __________________________
--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
DVR-Nr: 0005886
email: [email protected]
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
+43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
