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

[Mark Abraham]

Hi,

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()

Mark


On Sun, Aug 31, 2014 at 11:33 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca>
wrote:

> 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
> __________________________
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20140901/a603caad/attachment.html>