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

[Alan W. Irwin]

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
__________________________