[cmake-developers] Fortran detection, issue 9220

[Alan W. Irwin]

On 2015-02-06 10:21-0500 Ben Boeckel wrote:

> On Fri, Feb 06, 2015 at 07:01:55 +0100, Christoph Grüninger wrote:
>> would you mind to tackle issue 9220 "enable_language(.... OPTIONAL)
>> signature does not work correctly"? It's a shame that CMake cannot
>> properly detect optional Fortran for more than 5 years! The workaround
>> from Eigen works fine for me, but it's still embarrassing.
>>
>> BTW, is there a way to disable the optional Fortran by a flag to CMake?
>> I couldn't find any...
>
> Here is a commit which I haven't worked on for a while which delays the
> error until you request an actual build of a Fortran object:
>
>    https://github.com/mathstuf/CMake/commit/880d783bf7fbd986b8a50a712e69ff40abbcfa07
>
> While not the OPTIONAL signature, it is more accurate. Let me know how
> it works for you.

Some additional comments for both Christoph and Ben:

This issue is for all language compilers, not just Fortran, and this
issue is orthogonal to the well-known lack of support for Fortran in
ninja.

As the originator (almost 6 years ago) of this bug report I am still
very much interested in a fundamental solution to give a WARNING
message rather than an error if there is any issue with a compiler.
That capability is fundamentally important for projects like PLplot
that support more than one different compiled computer language
(PLplot supports the compiled languages Ada, C, C++, Fortran, D, and
Java) where the project developer's want users to at least have
partial functionality if say the Ada compiler does not work.  We do
have a workaround (see early comments in
http://public.kitware.com/Bug/view.php?id=9220 for details), but that
approach is inefficient (you have to check compilers twice), and
doesn't correctly propagate all the many different ways (e.g.,
environment variables, CMake cache variables) you can specify
compilers and compiler flags to the special small CMake test build
system used to check the compiler for each required compiled language.

The most recent comment (by Brad King) at
<http://public.kitware.com/Bug/view.php?id=9220> states the
documentation has now been changed to state that OPTIONAL is a
placeholder (in enable_language) that does not work.
So at least OPTIONAL has now been clearly marked as defunct.

Brad also recommends an alternative approach to using OPTIONAL in
enable_language.  I haven't had a chance to look into that possibility
yet, but I will do so because an efficient and clean solution for
providing a soft landing when a compiler test fails is important for
the PLplot project.

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
__________________________