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

[Marcel Loose]

Hi Alan,

Thanks for your elaborate reply. I had taken a look at the work-around
scripts that were upload for issue #9220 by you and Greg. They look
quite rigorous. I've come up with a much simplier but probably less
robust work-around.

# Work-around for CMake issue 0009220
if(DEFINED CMAKE_Fortran_COMPILER AND CMAKE_Fortran_COMPILER MATCHES "^
$")
  set(CMAKE_Fortran_COMPILER CMAKE_Fortran_COMPILER-NOTFOUND)
endif(DEFINED CMAKE_Fortran_COMPILER AND CMAKE_Fortran_COMPILER MATCHES
"^$") 

It seems to work OK, at least for me.

Best regards,
Marcel Loose.

On Thu, 2009-11-26 at 12:01 -0800, Alan W. Irwin wrote:
> 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
> __________________________