[CMake] What's the best way to support additional compilers for an "official" CMake language such as Fortran

[Brad King]

Alan W. Irwin wrote:
> messages for these files they deal with the following compilers/platforms.
> 
> * gfortran on Cygwin
> 
> * gfortran under MinGW

I think these work out of the box in 2.8.0.  However, there has been more
development since that release (see bottom of message).  They almost
certainly work in CVS HEAD.

> * Compaq Visual Fortran on Windows

I don't think this one has been tried in CMake upstream yet.

>> What change did you make to CMakeFortranInformation.cmake?  We should
>> be able to modify the CMake-provided version to do this.
> 
> I have attached a patch relative to the CMake-2.6.0 version of that file.
> Basically wherever CMAKE_ROOT is mentioned, you also have to give a
> CMake_MODULE_PATH alternative.

In CMake 2.8.0 there is never mention of CMAKE_ROOT in the Fortran info
file.

> a static PLplot library which in turn is linked to (a few) shared system
> libraries (which I am virtually positive are written in C rather than C++,

CMake only considers the languages of the libraries it builds when choosing
the linker language.  It does not try to detect if a system library has any
C++ in it (though there is a mechanism to tell CMake about it explicitly).

> If I simply put the unmodified version
> of the CMake 2.8 version of CMakeFortranInformation.cmake into our
> CMAKE_MODULE_PATH location, then the linker is chosen to be g++ which
> fails.
> If I remove CMakeFortranInformation.cmake completely from our
> CMAKE_MODULE_PATH location, then the linker is gfortran which succeeds.

So CMake chooses the right linker if you don't use modified language files?

> I assume Arjen would still be willing to donate all of the attached
> three files to the CMake project
[snip]
Arjen Markus wrote:
> As one of the developers in the PLplot project, who is moreover
> concerned with the support of Fortran, I would like to stress that we
> are quite prepared to submit the changes to existing modules or the
> additional modules to CMake. We can also test the modules for the
> various compilers that come with CMake within the context of PLplot.

Fortran support in CMake 2.8.0 is substantially different from 2.6.x.
Since 2.8.0 I've refactored many of the Platform/* and Compiler/*
module files to make adding new compilers easier.  Much of it will
probably be in 2.8.1.

You should be able to just put a couple files in your CMAKE_MODULE_PATH
to (almost) add a new compiler.  Files of the form

  Compiler/<id>-<lang>.cmake

have platform-independent info for a given compiler/language, and

  Platform/<os>-<id>-<lang>.cmake

have platform-specific info for a given compiler/language.  Here the
"<id>" is the CMAKE_<lang>_COMPILER_ID value, and <lang> is C, CXX,
or Fortran.

What's missing from CMake that makes adding compilers from new vendors
difficult is that the compiler id detection source code will not work.
The Modules/CMakeFortranCompilerId.F.in source file does not have an
entry for Compaq (but the C and CXX ones do).  Therefore CMake will
not recognize the compiler and look for *-Compaq-Fortran.cmake info
files.  This is one place that CMAKE_ROOT is still hard-coded (it
appears in CMakeDetermineCompilerId for the path to the compiler
id sources, and in CMakeDetermineFortranCompiler for the path to
CMakeDetermineCompilerId).  Unfortunately all of these files would
have to be copied/patched to add a new compiler id for 2.8.0.

As a first step, we can add Compaq to CMakeFortranCompilerId.F.in.
What is the preprocessor macro that identifies it?

The next step is to provide a way for projects to add their own
compiler id entries.  Since the compiler id sources are configured
we could easily add a way to add content to them.  I'll look at this.

Arjen, please try out each compiler of interest with CMake 2.8.0 and
with CMake from CVS HEAD.  Remove all plplot language module files
to see how much works out of the box.

Thanks,
-Brad