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 > __________________________ _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake