[CMake] cmake-gui leaves CMAKE_<language>_COMPILER_WORKS undefined for simple test case and CMake-2.6.4

[Clinton Stimpson]

I don't have much to say except that ccmake behaves the same as 
cmake-gui in this case.
You can add this at the end to see it.
set(MYSTATUS ${CMAKE_CXX_COMPILER_WORKS} CACHE STRING "")

Clint

On 07/15/2009 07:33 PM, Alan W. Irwin wrote:
> Here is a simple CMakeLists.txt test case that reveals what I believe 
> is a
> cmake-gui language bug.
>
> # stanza 1
> project(test NONE)
> cmake_minimum_required(VERSION 2.6.4)
>
> # stanza 2
> include(CMakeDetermineCXXCompiler)
> message(STATUS "CMAKE_CXX_COMPILER = ${CMAKE_CXX_COMPILER}")
>
> #stanza 3
> enable_language(CXX OPTIONAL)
> message(STATUS "CMAKE_CXX_COMPILER_WORKS = ${CMAKE_CXX_COMPILER_WORKS}")
>
> For the cmake application I get (in part)
>
> The CXX compiler identification is GNU
> CMAKE_CXX_COMPILER = /usr/bin/c++
> CMAKE_CXX_COMPILER_WORKS = 1
>
> For the cmake-gui application I get (in part)
> The CXX compiler identification is GNU
> CMAKE_CXX_COMPILER = /usr/bin/c++
> CMAKE_CXX_COMPILER_WORKS =
>
> Notice that CMAKE_CXX_COMPILER_WORKS is not defined for the cmake-gui 
> case.
>
> If I remove the second stanza above, I get
>
> CMAKE_CXX_COMPILER_WORKS = 1
>
> for both cmake and cmake-gui.
>
> Is this a cmake-gui bug or is it a bad idea to (semi-redundantly) run
>
> include(CMakeDetermineCXXCompiler)
>
> before
>
> enable_language(CXX OPTIONAL)
>
> Here is my use case for why I need to use the above pattern for our 
> PLplot
> builds.
>
> As I have reported before on list as well as at
> http://public.kitware.com/Bug/view.php?id=9220, OPTIONAL does not work
> correctly for enable_language.  If the compiler is missing or
> broken, enable_language _always_ errors out regardless of OPTIONAL. 
> Thus, no
> soft landing (i.e., give a warning message and disable the component 
> of the
> PLplot build that depends on the compiler and continuing) is yet possible
> based on the value of CMAKE_<language>_COMPILER_WORKS (for any language
> supported by CMake) derived in the third stanza above.
>
> In the PLplot case I have worked around this bug by using stanzas 
> similar to
> the second stanza above to obtain CMAKE_<language>_COMPILER.  Thus, at 
> least
> with this method I get a soft landing if the compiler is completely 
> missing
> rather than erroring out in enable_language(CXX OPTIONAL) before
> I can generate a soft landing based on CMAKE_CXX_COMPILER_WORKS.  The 
> method
> works fine for all our compiled languages (Ada, C++, D, Fortran, and 
> Java)
> that are optionally enabled beyond the basic C language that we need
> for our core library.
>
> But then one of our developers made the mistake of trying cmake-gui which
> left CMAKE_<language>_COMPILER_WORKS undefined in all cases and which
> therefore caused many build problems.  I can hack around that 
> cmake-gui bug
> by simply setting CMAKE_<language>_COMPILER_WORKS to ON after every
> enable_language(<language> OPTIONAL) call (i.e., take advantage of the
> erroring out so assume everything is fine if it returns at all), but this
> workaround on top of a workaround is just getting ridiculous!
>
> Here is the summary.
>
> I. cmake-gui should give the same CMAKE_<language>_COMPILER_WORKS 
> result as
> cmake unless there is some reason to never use
>
> include(CMakeDetermine<language>Compiler)
>
> before
>
> enable_language(<language> OPTIONAL)
>
> If the CMake developers agree that this combination should work for the
> cmake-gui application just like it does for the cmake application (i.e.,
> this is a cmake-gui bug) I will put it in the bug tracker, but I hope it
> does not languish there.
>
> II.  Even more importantly, I would like to see some action on the 
> above bug
> 9220. The CMakeDetermine<language>Compiler workaround should not be
> necessary for the missing compiler case, and that workaround does not 
> cover
> the broken compiler case.  Soft landings for both cases are important for
> projects with more than one language component such as PLplot.
>
> 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
> __________________________
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake