[CMake] --debug-trycompile not working as documented with the results being overwritten

Alan W. Irwin irwin at beluga.phys.uvic.ca
Sun Aug 31 17:33:21 EDT 2014


On 2014-08-31 12:43-0700 Alan W. Irwin wrote:

> I have the usual try_compile debug scenario; all but one of them in my
> project (PLplot) is working (some with expected false results some with 
> true),
> and I would like to debug the one that isn't working (the result
> is expected to be true, but it is false).
>
> 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."
>
> I have followed exactly that procedure on Linux with CMake-2.8.12.1,
> but at least one of the PLplot build system's other try_compile calls is 
> overwriting ./CMakeFiles/CMakeTmp/CMakeLists.txt so I cannot debug
> the try_compile I want to debug.
>
> Here are the details of all those different cached try_compile results.
> I run the following commands:
>
> software at raven> cmake \
> -DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake \
> -DBUILD_TEST=ON ../plplot.git >& cmake.out
>
> edit CMakeCache to remove the two lines relevant to the try_compile
> I want to debug:
> //Result of TRY_COMPILE
> CONSISTENT_HEADER_ITCL_VERSION:INTERNAL=FALSE
>
> software at raven> cmake --debug-trycompile \
> -DCMAKE_INSTALL_PREFIX=/home/software/plplot/installcmake
> -DBUILD_TEST=ON ../plplot.git >& cmake.out1
>
> software at raven> grep -A1 TRY_COMPILE CMakeCache.txt
> //Result of TRY_COMPILE
> CMAKE_BROKEN_ISNAN_CXX:INTERNAL=TRUE
> --
> //Result of TRY_COMPILE
> CMAKE_CXX_STDINT_H:INTERNAL=TRUE
> --
> //Result of TRY_COMPILE
> CMAKE_D_TANGO_WORKS:INTERNAL=FALSE
> --
> //Result of TRY_COMPILE
> CMAKE_FORTRAN_HAVE_ISNAN:INTERNAL=FALSE
> --
> //Result of TRY_COMPILE
> CMAKE_HIGH_BIT_CHARACTERS:INTERNAL=TRUE
> --
> //Result of TRY_COMPILE
> CMAKE_TEST_SIGNAL_TYPE:INTERNAL=TRUE
> --
> //Result of TRY_COMPILE
> CMAKE_USE_NAMESPACE:INTERNAL=TRUE
> --
> //Result of TRY_COMPILE
> CONSISTENT_HEADER_ITCL_VERSION:INTERNAL=FALSE
> //Result of TRY_COMPILE
> COMPILE_RESULT:INTERNAL=TRUE
> //Result of TRY_COMPILE
> CONSISTENT_HEADER_ITK_VERSION:INTERNAL=TRUE
> --
> //Result of TRY_COMPILE
> HAVE_SAHOOKS:INTERNAL=TRUE
>
> By looking at CMakeFiles/CMakeTmp/CMakeLists.txt I have discovered it
> is the HAVE_SAHOOKS one that last overwrites the
> CMakeFiles/CMakeTmp/CMakeLists.txt file for the second CMake
> invocation.  Also, notice that the one I removed,
> CONSISTENT_HEADER_ITCL_VERSION is restored indicating that try_compile
> was executed (and returned a failure which I am trying to debug, but I
> cannot do that with CMakeFiles/CMakeTmp/CMakeLists.txt being
> overwritten).
>
> The last time I had to debug a try_compile was years ago, but as far
> as I can remember in that case --debug-trycompile worked as
> documented.  And technically --debug-trycompile works for this case as
> well (CMakeFiles/CMakeTmp/CMakeLists.txt is retained for each
> try_compile). But in practice it is useless because the other
> try_compiles are overwriting the results.  Is there some known bugs
> for cmake-2.8.12.x such that try_compiles are repeated even if a
> cached result (whether true of false) is found for the resulting
> variable?  (For what it is worth, note that HAVE_SAHOOKS is true
> above.)

Some further information.  The HAVE_SAHOOKS try_compile that keeps repeating
regardless is implemented as follows:

   # See if shapelib is a modern version with access to SAHooks type.
   file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/Check_SAHooks.c
     "#include <shapefil.h>
void main(void){SAHooks sHooks;}
"
     )
   try_compile(HAVE_SAHOOKS ${CMAKE_BINARY_DIR}
     ${CMAKE_CURRENT_BINARY_DIR}/Check_SAHooks.c
     CMAKE_FLAGS "-DINCLUDE_DIRECTORIES:STRING=${SHAPELIB_INCLUDE_DIR}"
     )

I thought perhaps the repeat was caused by that "file(WRITE...." command
rewriting out the file with a new date for the second cmake
invocation, but I tried some

if(NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/Check_SAHooks.c)

logic (which worked, that file was not redated on second cmake call),
but the above try_compile still overwrites CMakeFiles/CMakeTmp/CMakeLists.txt
for the second cmake invocation with --debug-trycompile.

I would appreciate hearing from anyone here that has had success with
debug try_compile for recent CMake versions when there is at least one
other try_compile invocation that is interfering.

For now, though, to work around what I am beginning to think is a
cmake bug I am going to surround the entire block of above code with
if(NOT DEFINED HAVE_SAHOOKS) (and similarly for any other try_compiles
that are currently interfering with the one I want to debug).

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
__________________________


More information about the CMake mailing list