Re: enable_language( ... OPTIONAL) causes error or second cmake run

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: enable_language( ... OPTIONAL) causes error or second cmake run

Marcel Loose
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
Reply | Threaded
Open this post in threaded view
|

Re: enable_language( ... OPTIONAL) causes error or second cmake run

Alexander Neundorf-3
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
Reply | Threaded
Open this post in threaded view
|

Re: enable_language( ... OPTIONAL) causes error or second cmake run

Marcel Loose
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
Reply | Threaded
Open this post in threaded view
|

Re: enable_language( ... OPTIONAL) causes error or second cmake run

Marcel Loose
In reply to this post by Marcel Loose
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
Reply | Threaded
Open this post in threaded view
|

Re: 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
__________________________
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: enable_language( ... OPTIONAL) causes error or second cmake run

Marcel Loose
In reply to this post by 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
> __________________________

_______________________________________________
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