Re: [CMake] enable_language( ... OPTIONAL) causes error on second cmake run
Hi Alex,
I've written a very small work-around for my problem.
I noted that 'enable_language(Fortran)' sets the compiler to
CMAKE_Fortran_COMPILER-NOTFOUND, whereas 'enable_language(Fortran
OPTIONAL) sets it to the empty string. So what I do now is check whether
CMAKE_Fortran_COMPILER is defined and matches the empty string, and if
so, I set it to CMAKE_Fortran_COMPILER-NOTFOUND. I had expected that I
should set it as a cache variable, but it only seems to work if I set it
as a normal variable.
# Work-around for CMake issue #9220
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
^$)
I'll add this work-around to the notes for issue #9220.
Best regards,
Marcel Loose.
On Thu, 2009-11-26 at 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?
Best regards,
Marcel Loose.
On Wed, 2009-11-25 at 19:16 +0100, Alexander Neundorf wrote:
On Wednesday 25 November 2009, Marcel Loose wrote:
Hi Alex,
Maybe I'm overlooking all kinds of side effects, but the problem is in
line 6 of CMakeFortranInformation.cmake, where get_filename_component()
is called with an incorrect number of arguments. This happens because
${CMAKE_Fortran_COMPILER} is empty. If I simply put quotes around
${CMAKE_Fortran_COMPILER} the problem is solved. Or so it seems. Right,
or wrong?
I think there's more to it IIRC, the rest of the enable-language process
has
to be canceled correctly, which is probably not the case with your fix.
But please put this comment in the bugtracker, so it doesn't get lost.
Alex
___
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
___
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
Re: [CMake] enable_language( ... OPTIONAL) causes error or second cmake run
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
Re: [CMake] enable_language( ... OPTIONAL) causes error or second cmake run
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?
Best regards,
Marcel Loose.
On Wed, 2009-11-25 at 19:16 +0100, Alexander Neundorf wrote:
On Wednesday 25 November 2009, Marcel Loose wrote:
Hi Alex,
Maybe I'm overlooking all kinds of side effects, but the problem is in
line 6 of CMakeFortranInformation.cmake, where get_filename_component()
is called with an incorrect number of arguments. This happens because
${CMAKE_Fortran_COMPILER} is empty. If I simply put quotes around
${CMAKE_Fortran_COMPILER} the problem is solved. Or so it seems. Right,
or wrong?
I think there's more to it IIRC, the rest of the enable-language process has
to be canceled correctly, which is probably not the case with your fix.
But please put this comment in the bugtracker, so it doesn't get lost.
Alex
___
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
Re: [CMake] enable_language( ... OPTIONAL) causes error or second cmake run
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
Re: [CMake] enable_language( ... OPTIONAL) causes error or second cmake run
Hi Alex,
Maybe I'm overlooking all kinds of side effects, but the problem is in
line 6 of CMakeFortranInformation.cmake, where get_filename_component()
is called with an incorrect number of arguments. This happens because
${CMAKE_Fortran_COMPILER} is empty. If I simply put quotes around
${CMAKE_Fortran_COMPILER} the problem is solved. Or so it seems. Right,
or wrong?
Best regards,
Marcel Loose.
On Tue, 2009-11-24 at 19:48 +0100, Alexander Neundorf wrote:
On Tuesday 24 November 2009, Marcel Loose wrote:
Hi all,
I've been experimenting a bit with enable_language() and stumbled upon
what I think is a bug.
Yes: http://public.kitware.com/Bug/view.php?id=9220
It's not trivial to make it work.
Alex
___
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
Re: [CMake] enable_language( ... OPTIONAL) causes error or second cmake run
On Wednesday 25 November 2009, Marcel Loose wrote:
Hi Alex,
Maybe I'm overlooking all kinds of side effects, but the problem is in
line 6 of CMakeFortranInformation.cmake, where get_filename_component()
is called with an incorrect number of arguments. This happens because
${CMAKE_Fortran_COMPILER} is empty. If I simply put quotes around
${CMAKE_Fortran_COMPILER} the problem is solved. Or so it seems. Right,
or wrong?
I think there's more to it IIRC, the rest of the enable-language process has
to be canceled correctly, which is probably not the case with your fix.
But please put this comment in the bugtracker, so it doesn't get lost.
Alex
___
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
Re: [CMake] enable_language( ... OPTIONAL) causes error or second cmake run
Done, see Note 0018597
Best regards,
Marcel Loose.
On Wed, 2009-11-25 at 19:16 +0100, Alexander Neundorf wrote:
On Wednesday 25 November 2009, Marcel Loose wrote:
Hi Alex,
Maybe I'm overlooking all kinds of side effects, but the problem is in
line 6 of CMakeFortranInformation.cmake, where get_filename_component()
is called with an incorrect number of arguments. This happens because
${CMAKE_Fortran_COMPILER} is empty. If I simply put quotes around
${CMAKE_Fortran_COMPILER} the problem is solved. Or so it seems. Right,
or wrong?
I think there's more to it IIRC, the rest of the enable-language process has
to be canceled correctly, which is probably not the case with your fix.
But please put this comment in the bugtracker, so it doesn't get lost.
Alex
___
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
[CMake] enable_language( ... OPTIONAL) causes error or second cmake run
Hi all, I've been experimenting a bit with enable_language() and stumbled upon what I think is a bug. I have wanted to know how to properly handle a missing Fortran compiler. So, on a system without a working Fortran compiler I ran cmake twice. In the first cmake run, the Fortran compiler is searched and not found. However, the second run of cmake then causes an error, which IMHO should not happen. This happens with CMake 2.6.2 and 2.8.0 $ cat ../CMakeLists.txt project(Dummy) cmake_minimum_required(VERSION 2.6) enable_language(Fortran OPTIONAL) $ cmake .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- The Fortran compiler identification is unknown -- Configuring done -- Generating done -- Build files have been written to: /tmp/loose/cmake/build $ cmake .. -- The Fortran compiler identification is unknown CMake Error at /dop131_0/loose/x86_64-linux/usr/share/cmake-2.8/Modules/CMakeFortranInformation.cmake:25 (GET_FILENAME_COMPONENT): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): CMakeLists.txt:3 (enable_language) -- Configuring incomplete, errors occurred! Best regards, Marcel Loose. ___ 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
Re: [CMake] enable_language( ... OPTIONAL) causes error or second cmake run
On Tuesday 24 November 2009, Marcel Loose wrote: Hi all, I've been experimenting a bit with enable_language() and stumbled upon what I think is a bug. Yes: http://public.kitware.com/Bug/view.php?id=9220 It's not trivial to make it work. Alex ___ 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
