[CMake] Additional testing of bug #4772

[Alan W. Irwin]

On 2008-09-22 20:12-0700 Alan W. Irwin wrote:

> Now that we have an example of a working ENABLE_LANGUAGE for gfortran, I
> agree with your assessment/guess that the CXX and C troubles for that case
> are some screw up in one of the C and CXX (but not Fortran) enabling files
> in Platform.  In fact I am on the track of something
> (CMAKE_C_FLAGS_DEBUG_INIT appears not to be initialized for the generic
> Linux case and also not for the specific gcc case in Platform) and will
> report further later tonight or tomorrow.

The above comment about CMAKE_C_FLAGS_DEBUG_INIT is not correct.  Here is
the CMake logic I have traced so far:

According to a note in that file (although this needs to be confirmed by
looking at the source code) CMakeSystemSpecificInformation.cmake is included
by cmGlobalGenerator::EnableLanguage.  That file in turn INCLUDEs
CMakeGenericSystem.cmake which in turn INCLUDEs Platform/gcc.cmake which
defines CMAKE_C_FLAGS_DEBUG_INIT for the case of IF(CMAKE_COMPILER_IS_GNUCC)
and CMAKE_CXX_FLAGS_DEBUG_INIT for the case of IF(CMAKE_COMPILER_IS_GNUCXX).

The tests below have been done this time consistently for 2.6.1.

  PROJECT(free_eos CXX)
  ENABLE_LANGUAGE(C)

==>

CMAKE_CXX_FLAGS_DEBUG:STRING=-g
CMAKE_C_FLAGS_DEBUG:STRING=

i.e., I get the same bad result for 2.6.1 as I did 
for 2.6.0 which is not a surprise.

However, if I create the file Platform/Linux-gcc.cmake as a copy
of Platform/gcc.cmake (by analogy with Platform/Linux-GNU-Fortran.cmake)
the same test gives me the good result,

CMAKE_CXX_FLAGS_DEBUG:STRING=-g
CMAKE_C_FLAGS_DEBUG:STRING=-g

Therefore, the above logic that I traced for Platform/gcc.cmake must be
failing somehow (perhaps one or both of CMAKE_COMPILER_IS_GNUCC or
CMAKE_COMPILER_IS_GNUCXX is undefined when CMakeGenericSystem.cmake is
INCLUDEd or one of CMAKE_C_FLAGS_DEBUG_INIT or CMAKE_CXX_FLAGS_DEBUG_INIT
(depending on what language is defined by PROJECT and what language
by ENABLE_LANGUAGE) is set to nothing by subsequent logic).

So it appears that creating the file Platform/Linux-gcc.cmake as a copy of
Platform/gcc.cmake solves the above issue.

However, I then made the mistake of making further experiments for that
case, and I could not get ENABLE_LANGUAGE(CXX) to ever work properly.

For example, if I reverse the above two languages, e.g.,

  PROJECT(free_eos C)
  ENABLE_LANGUAGE(CXX)

or try either

  PROJECT(free_eos NONE)
  ENABLE_LANGUAGE(CXX)
  ENABLE_LANGUAGE(C)

or

  PROJECT(free_eos NONE)
  ENABLE_LANGUAGE(C)
  ENABLE_LANGUAGE(CXX)

then

==>

CMAKE_CXX_FLAGS_DEBUG:STRING=
CMAKE_C_FLAGS_DEBUG:STRING=-g

i.e., for all three of these patterns C is fine, and C++ is screwed up.

In sum, the above creation of Platform/Linux-gcc.cmake goes through the
identical logic as Platform/gcc.cmake but at a different time (with
variables initialized differently I presume).  That subtle change in when
that logic is done apparently solves the ENABLE_LANGUAGE(C) case, but not
the ENABLE_LANGUAGE(CXX) case.

Bill, can you or someone else from Kitware take over now to finish this off?
If you don't have immediate access to Linux, I am willing to do any
experiments you suggest on that platform.  Currently, I feel I am
floundering around close to the solution of the problem on my own, but I
think it will require somebody with more comprehensive CMake language
support expertise than mine to determine a really elegant solution for this
Platform bug that works not only for C, but also for CXX in the Linux gcc
case.

By the way, although ENABLE_LANGUAGE(C) works for Linux/gcc with the above
change and ENABLE_LANGUAGE(Fortran) works regardless for Linux/gfortran, the
ENABLE_LANGUAGE(CXX) case is important from the PLplot perspective since our
core library is just C. Thus, when our users enable C++, a set of C++
bindings for that library is created that is analogous to our other optional
language bindings.  Right now our users are reasonably happy with our
current CMake-based build system which specifies both C and CXX through our
project statement. Of course, that logic demands they have a C++ compiler,
but that is not too onerous a requirement since C++ compilers are often
installed when a C compiler is installed. However, we did have one complaint
from a user who was stuck with just a C compiler and I would like to
accomodate him (and others in the same category) by making C++ optional as
soon as the ENABLE_LANGUAGE(CXX) case is straightened out for
CMake/Linux/gcc.

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
__________________________