Preliminaries to this topic have already been posted on the cmake
list, but the only response there (from Mark Abraham) was
"Raw try_compile is not a great idiom for general use (though it is
unclear why it is not working well for you). Using the
Modules/Check*cmake gear is a much better option, e.g. with
check_symbol_exists()"
which was useful in working around the issue, but not responsive about
the issue itself which I now believe is a try_compile documentation
bug.
The (CMake-2.8.12.1) documentation says:
"If you use --debug-trycompile, you can only debug one try_compile call
at a time. The recommended procedure is to configure with cmake all
the way through once, then delete the cache entry associated with the
try_compile call of interest, and then re-run cmake again with
--debug-trycompile."
That implies every call to the second signature of try_compile, i.e.,
try_compile(RESULT_VAR <bindir> <srcfile> [optional arguments])
is implicitly protected inside the implementation of try_compile by
if(NOT DEFINED RESULT_VAR)
[...]
endif(NOT DEFINED RESULT_VAR)
logic, but my tests show this is not the case and
this second form of try_compile signature always repeated
no matter if RESULT_VAR is defined or not in the cache.
In fact, if you look at all the try_compile usage in
Modules/Check*cmake, every such try_compile call is
protected _outside_ the call by either
if(NOT DEFINED VARIABLE)
logic or the equivalent (using CMake logic available in 2006 (!))
if("${VARIABLE}" MATCHES "^${VARIABLE}$")
logic. Which in turn implies all the different writers of the
Modules/Check*cmake modules were well aware over the years that
try_compile repeats (unless protected by such DEFINED logic) for each
cmake invocation contrary to the above try_compile documentation.
So to fix this documentation bug, I suggest
This recommended procedure obviously only works if every try_compile call using
the second signature in any given build system is protected by "if(NOT
DEFINED RESULT_VAR)" logic.
be appended to the try_compile documentation.
I am willing to write this up as a bug report, but I believe this bug
fix is pretty much a no-brainer which requires only checking my
experimental results that the try_compile implementation is not
protected internally by a DEFINED check of the variable before adding
the above sentence to the documentation. So I hope to convince a
CMake developer to just go ahead an fix this documentation bug without
going through the normal dance of putting it on the bug tracker,
watching it get ignored there because of all the noise from
low-quality bug reports there, keep advocating here this really is a
useful documentation fix, etc.
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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__________________________
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
