[CMake] enable_language( ... OPTIONAL) causes error or second cmake run

[Alan W. Irwin]

On 2009-11-26 16:12+0100 Marcel Loose wrote:

> Hi Alex,
>
> On second thought: the problem I encountered is somewhat different than
> the one described in issue #9220. The problem there is that the compiler
> name "gcc whatever" is interpreted as compiler "gcc" with an argument
> "whatever".
>
> In my case I do not set a compiler from the command line. I use
> 'enable_language(Fortran OPTIONAL)' and let CMake search for the Fortran
> compiler. Since there's no Fortran compiler installed, CMake will not
> find it. So far, so good. But, when I run CMake a second time, I get the
> error I reported.
>
> What's your thought on this?

Sorry to enter the conversation late, but 9220 is the bug I reported, and
"gcc whatever" was simply a test of how CMake responded to a non-working
compiler, and the OPTIONAL signature fails in many other ways as well.
Basically, I suggest you do not use the OPTIONAL signature until bug 9220
has been fixed.  One way to avoid OPTIONAL is to use the workaround for bug
9220 that I implemented.  (The bug report discussion in mantis has an early
version of the workaround.  The latest can be seen at
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/language_support.cmake?view=log
There are some PLplot-specific things in this workaround (for example,
dealing with D and Ada as special cases) which you won't need for your own
project's language needs.

The workaround uses execute_process to run cmake with enable_language
(without the OPTIONAL signature) for the appropriate language, and if the
return code shows an error occurred, then you know the appropriate compiler
for the language is missing/broken. Thus, with this method you can give
users a soft landing for missing/broken compilers with appropriate warning
messages, drop support for that language (for example, in PLplot we have a
number of compiled languages we optionally support including Ada and D), and
move on with the rest of the build.

Except for potential inconsistency issues (see further discussion below),
the workaround should be robust since whenever the compiler is
missing/broken, execute_process should always give a return code that shows
something wrong with the compiler.  So I suggest you give a variant of my
workaround that is suitable for your own project's language needs a try.

The one known case where the workaround is not robust is when there is some
inconsistency between the language enviroment for the execute_process
version of cmake and the "master" cmake. In fact, for the PLplot version of
the workaround we only pass on to the execute_process version of cmake the
compiler flags set with environment variables. So if a user sets a compiler
flag incorrectly by some other method, the PLplot version of the workaround
cannot warn you about that situation, and the PLplot user gets a hard
landing (Cmake Error) from the master cmake session.

Because of this potential inconsistency issue, fixing bug 9220 is preferable
to the workaround.  However, the workaround should be a "useful temporary
measure" (famous last words!) to deal with missing/broken compilers until
that bug gets fixed.

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
__________________________