cmake-gui leaves CMAKE_<language>_COMPILER_WORKS undefined for simple test case and CMake-2.6.4

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

cmake-gui leaves CMAKE_<language>_COMPILER_WORKS undefined for simple test case and CMake-2.6.4

Alan W. Irwin
Here is a simple CMakeLists.txt test case that reveals what I believe is a
cmake-gui language bug.

# stanza 1
project(test NONE)
cmake_minimum_required(VERSION 2.6.4)

# stanza 2
include(CMakeDetermineCXXCompiler)
message(STATUS "CMAKE_CXX_COMPILER = ${CMAKE_CXX_COMPILER}")

#stanza 3
enable_language(CXX OPTIONAL)
message(STATUS "CMAKE_CXX_COMPILER_WORKS = ${CMAKE_CXX_COMPILER_WORKS}")

For the cmake application I get (in part)

The CXX compiler identification is GNU
CMAKE_CXX_COMPILER = /usr/bin/c++
CMAKE_CXX_COMPILER_WORKS = 1

For the cmake-gui application I get (in part)
The CXX compiler identification is GNU
CMAKE_CXX_COMPILER = /usr/bin/c++
CMAKE_CXX_COMPILER_WORKS =

Notice that CMAKE_CXX_COMPILER_WORKS is not defined for the cmake-gui case.

If I remove the second stanza above, I get

CMAKE_CXX_COMPILER_WORKS = 1

for both cmake and cmake-gui.

Is this a cmake-gui bug or is it a bad idea to (semi-redundantly) run

include(CMakeDetermineCXXCompiler)

before

enable_language(CXX OPTIONAL)

Here is my use case for why I need to use the above pattern for our PLplot
builds.

As I have reported before on list as well as at
http://public.kitware.com/Bug/view.php?id=9220, OPTIONAL does not work
correctly for enable_language.  If the compiler is missing or
broken, enable_language _always_ errors out regardless of OPTIONAL. Thus, no
soft landing (i.e., give a warning message and disable the component of the
PLplot build that depends on the compiler and continuing) is yet possible
based on the value of CMAKE_<language>_COMPILER_WORKS (for any language
supported by CMake) derived in the third stanza above.

In the PLplot case I have worked around this bug by using stanzas similar to
the second stanza above to obtain CMAKE_<language>_COMPILER.  Thus, at least
with this method I get a soft landing if the compiler is completely missing
rather than erroring out in enable_language(CXX OPTIONAL) before
I can generate a soft landing based on CMAKE_CXX_COMPILER_WORKS.  The method
works fine for all our compiled languages (Ada, C++, D, Fortran, and Java)
that are optionally enabled beyond the basic C language that we need
for our core library.

But then one of our developers made the mistake of trying cmake-gui which
left CMAKE_<language>_COMPILER_WORKS undefined in all cases and which
therefore caused many build problems.  I can hack around that cmake-gui bug
by simply setting CMAKE_<language>_COMPILER_WORKS to ON after every
enable_language(<language> OPTIONAL) call (i.e., take advantage of the
erroring out so assume everything is fine if it returns at all), but this
workaround on top of a workaround is just getting ridiculous!

Here is the summary.

I. cmake-gui should give the same CMAKE_<language>_COMPILER_WORKS result as
cmake unless there is some reason to never use

include(CMakeDetermine<language>Compiler)

before

enable_language(<language> OPTIONAL)

If the CMake developers agree that this combination should work for the
cmake-gui application just like it does for the cmake application (i.e.,
this is a cmake-gui bug) I will put it in the bug tracker, but I hope it
does not languish there.

II.  Even more importantly, I would like to see some action on the above bug
9220. The CMakeDetermine<language>Compiler workaround should not be
necessary for the missing compiler case, and that workaround does not cover
the broken compiler case.  Soft landings for both cases are important for
projects with more than one language component such as PLplot.

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
|  
Report Content as Inappropriate

Re: cmake-gui leaves CMAKE_<language>_COMPILER_WORKS undefined for simple test case and CMake-2.6.4

Clinton Stimpson

I don't have much to say except that ccmake behaves the same as
cmake-gui in this case.
You can add this at the end to see it.
set(MYSTATUS ${CMAKE_CXX_COMPILER_WORKS} CACHE STRING "")

Clint

On 07/15/2009 07:33 PM, Alan W. Irwin wrote:

> Here is a simple CMakeLists.txt test case that reveals what I believe
> is a
> cmake-gui language bug.
>
> # stanza 1
> project(test NONE)
> cmake_minimum_required(VERSION 2.6.4)
>
> # stanza 2
> include(CMakeDetermineCXXCompiler)
> message(STATUS "CMAKE_CXX_COMPILER = ${CMAKE_CXX_COMPILER}")
>
> #stanza 3
> enable_language(CXX OPTIONAL)
> message(STATUS "CMAKE_CXX_COMPILER_WORKS = ${CMAKE_CXX_COMPILER_WORKS}")
>
> For the cmake application I get (in part)
>
> The CXX compiler identification is GNU
> CMAKE_CXX_COMPILER = /usr/bin/c++
> CMAKE_CXX_COMPILER_WORKS = 1
>
> For the cmake-gui application I get (in part)
> The CXX compiler identification is GNU
> CMAKE_CXX_COMPILER = /usr/bin/c++
> CMAKE_CXX_COMPILER_WORKS =
>
> Notice that CMAKE_CXX_COMPILER_WORKS is not defined for the cmake-gui
> case.
>
> If I remove the second stanza above, I get
>
> CMAKE_CXX_COMPILER_WORKS = 1
>
> for both cmake and cmake-gui.
>
> Is this a cmake-gui bug or is it a bad idea to (semi-redundantly) run
>
> include(CMakeDetermineCXXCompiler)
>
> before
>
> enable_language(CXX OPTIONAL)
>
> Here is my use case for why I need to use the above pattern for our
> PLplot
> builds.
>
> As I have reported before on list as well as at
> http://public.kitware.com/Bug/view.php?id=9220, OPTIONAL does not work
> correctly for enable_language.  If the compiler is missing or
> broken, enable_language _always_ errors out regardless of OPTIONAL.
> Thus, no
> soft landing (i.e., give a warning message and disable the component
> of the
> PLplot build that depends on the compiler and continuing) is yet possible
> based on the value of CMAKE_<language>_COMPILER_WORKS (for any language
> supported by CMake) derived in the third stanza above.
>
> In the PLplot case I have worked around this bug by using stanzas
> similar to
> the second stanza above to obtain CMAKE_<language>_COMPILER.  Thus, at
> least
> with this method I get a soft landing if the compiler is completely
> missing
> rather than erroring out in enable_language(CXX OPTIONAL) before
> I can generate a soft landing based on CMAKE_CXX_COMPILER_WORKS.  The
> method
> works fine for all our compiled languages (Ada, C++, D, Fortran, and
> Java)
> that are optionally enabled beyond the basic C language that we need
> for our core library.
>
> But then one of our developers made the mistake of trying cmake-gui which
> left CMAKE_<language>_COMPILER_WORKS undefined in all cases and which
> therefore caused many build problems.  I can hack around that
> cmake-gui bug
> by simply setting CMAKE_<language>_COMPILER_WORKS to ON after every
> enable_language(<language> OPTIONAL) call (i.e., take advantage of the
> erroring out so assume everything is fine if it returns at all), but this
> workaround on top of a workaround is just getting ridiculous!
>
> Here is the summary.
>
> I. cmake-gui should give the same CMAKE_<language>_COMPILER_WORKS
> result as
> cmake unless there is some reason to never use
>
> include(CMakeDetermine<language>Compiler)
>
> before
>
> enable_language(<language> OPTIONAL)
>
> If the CMake developers agree that this combination should work for the
> cmake-gui application just like it does for the cmake application (i.e.,
> this is a cmake-gui bug) I will put it in the bug tracker, but I hope it
> does not languish there.
>
> II.  Even more importantly, I would like to see some action on the
> above bug
> 9220. The CMakeDetermine<language>Compiler workaround should not be
> necessary for the missing compiler case, and that workaround does not
> cover
> the broken compiler case.  Soft landings for both cases are important for
> projects with more than one language component such as PLplot.
>
> 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


_______________________________________________
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
|  
Report Content as Inappropriate

Re: cmake-gui leaves CMAKE_<language>_COMPILER_WORKS undefined for simple test case and CMake-2.6.4

Alan W. Irwin
In reply to this post by Alan W. Irwin
On 2009-07-15 18:33-0700 Alan W. Irwin wrote:

> But then one of our developers made the mistake of trying cmake-gui which
> left CMAKE_<language>_COMPILER_WORKS undefined in all cases and which
> therefore caused many build problems.  I can hack around that cmake-gui bug
> by simply setting CMAKE_<language>_COMPILER_WORKS to ON after every
> enable_language(<language> OPTIONAL) call (i.e., take advantage of the
> erroring out so assume everything is fine if it returns at all), but this
> workaround on top of a workaround is just getting ridiculous!

It turns out that suggested workaround for the cmake-gui issue with the
OPTIONAL workaround doesn't work for PLplot.  For example, cmake-gui leaves
the essential fortran variable, CMAKE_Fortran_COMPILER_SUPPORTS_F90,
undefined as well as CMAKE_Fortran_COMPILER_WORKS.  That's just one example,
of an essential undefined language variable with cmake-gui and I suspect
there are others for other languages. Thus, I currently have the choice of
telling PLplot users to not use cmake-gui or change our build system to give
users a hard landing if they have any (!) of Ada, C++, D, Fortran, or Java
development environment missing.

That's a pretty ugly choice so timely help would be much appreciated with
http://public.kitware.com/Bug/view.php?id=9220 to insure the fix gets into
cmake-2.6.5 so the OPTIONAL signature of enable_language "just works" for C,
C++, Fortran, and Java. (I can follow along with similar changes for Ada and
D [additional languages which I support locally as part of PLplot] once the
CMake C++ source code itself for the OPTIONAL signature of enable_language
sets a global CMake variable that can be used to bypass MESSAGE(FATAL_ERROR
...) in the current CMake language support scripts.)

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
|  
Report Content as Inappropriate

Re: cmake-gui leaves CMAKE_<language>_COMPILER_WORKS undefined for simple test case and CMake-2.6.4

Alan W. Irwin
In reply to this post by Clinton Stimpson
On 2009-07-15 22:54-0600 Clinton Stimpson wrote:

>
> I don't have much to say except that ccmake behaves the same as cmake-gui in
> this case.
> You can add this at the end to see it.
> set(MYSTATUS ${CMAKE_CXX_COMPILER_WORKS} CACHE STRING "")

Thanks for pointing that out.  This can of worms just keeps getting worse
and worse.  I have confirmed your ccmake result by looking in the resulting
CMakeCache.txt file where (unlike the cmake result) no reference to
CMAKE_CXX_COMPILER_WORKS appears.

So is the issue some cache problem with language support that is exposed for
both ccmake and cmake-gui, but not cmake?

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
|  
Report Content as Inappropriate

Re: cmake-gui leaves CMAKE_<language>_COMPILER_WORKS undefined for simple test case and CMake-2.6.4

Bill Hoffman
Alan W. Irwin wrote:

> On 2009-07-15 22:54-0600 Clinton Stimpson wrote:
>
>>
>> I don't have much to say except that ccmake behaves the same as
>> cmake-gui in this case.
>> You can add this at the end to see it.
>> set(MYSTATUS ${CMAKE_CXX_COMPILER_WORKS} CACHE STRING "")
>
> Thanks for pointing that out.  This can of worms just keeps getting worse
> and worse.  I have confirmed your ccmake result by looking in the resulting
> CMakeCache.txt file where (unlike the cmake result) no reference to
> CMAKE_CXX_COMPILER_WORKS appears.
>

I am not really sure what this issue is...


This is certainly not an expected use case:

include(CMakeDetermine<language>Compiler)
before
enable_language(<language> OPTIONAL)

If you look in cmGlobalGenerator.cxx there is a big comment about how
all the files work together to enable a language.  I am not surprised
that including this stuff out of order is causing trouble.  I am also
not sure why the gui's would be different...

The right thing would be to implement the OPTIONAL part.  I don't know
if I will have time for this before 2.8 (patches are welcome...).  As a
work around I would suggest trying to find a compiler with the same
algorithm as CMakeDetermine does.  I can try to help you implement if
you want...

-Bill
_______________________________________________
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
|  
Report Content as Inappropriate

Re: cmake-gui leaves CMAKE_<language>_COMPILER_WORKS undefined for simple test case and CMake-2.6.4

Alan W. Irwin
On 2009-07-16 13:51-0400 Bill Hoffman wrote:

> I am not really sure what this issue is...
>
>
> This is certainly not an expected use case:
>
> include(CMakeDetermine<language>Compiler)
> before
> enable_language(<language> OPTIONAL)
>
> If you look in cmGlobalGenerator.cxx there is a big comment about how all
the$
> files work together to enable a language.  I am not surprised that including
> this stuff out of order is causing trouble.  I am also not sure why the gui's
> would be different...
>
> The right thing would be to implement the OPTIONAL part.  I don't know if I
> will have time for this before 2.8 (patches are welcome...).

With regard to the differences between the good cmake results on the one
hand and the bad ccmake and cmake-gui results on on the other hand for my
simple but nonstandard example, I agree that CMake language support is sort
of a "magical" area of CMake so it is perhaps not too surprising that using
it in this unanticipated way exposes differences between the various cmake
applications. So given your time constraints you may want to just cross your
fingers and let this exposed issue slide.

However, that exposed issue was discovered because I needed a workaround for
bug 9220 so I agree the fundamental thing to do would be to deal with bug
9220.

On 2009-07-16 14:12-0400 Bill Hoffman wrote:

> David Cole wrote:
>> Another work around might be doing an execute_process with another CMake
>> that processes a one-line file with an enable_language call in it... If it
>> fails to configure, the caller of execute_process could fail gracefully
>> rather than with the hard error that an enable_language call currently
>> gives. And if it succeeds, then presumably it would be safe to call
>> enable_language for that language... You'd have to use your own variables
>> to track with this technique and not rely on the built-in ones.
>>
>
> That is a good idea, and it would work with any version of cmake.

Hi David:

I think you inadvertently posted your comment off list so I hope you don't
mind if I quote you (and also Bill's response to your idea) on list.

Thanks for that good idea for a temporary workaround to bug 9220. Your idea
even takes care of the broken compiler case.  (My attempted workaround only
took care of the missing compiler case.) I will implement that workaround
for now for the PLplot build system, but that's a little complicated for
most projects that want to implement a soft landing when compilers are
missing/broken.  So fixing bug 9220 is obviously the best long-term
solution.

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
|  
Report Content as Inappropriate

Re: cmake-gui leaves CMAKE_<language>_COMPILER_WORKS undefined for simple test case and CMake-2.6.4

David Cole
On Thu, Jul 16, 2009 at 4:23 PM, Alan W. Irwin <[hidden email]> wrote:
On 2009-07-16 13:51-0400 Bill Hoffman wrote:

I am not really sure what this issue is...


This is certainly not an expected use case:

include(CMakeDetermine<language>Compiler)
before
enable_language(<language> OPTIONAL)

If you look in cmGlobalGenerator.cxx there is a big comment about how all
the$
files work together to enable a language.  I am not surprised that including
this stuff out of order is causing trouble.  I am also not sure why the gui's
would be different...

The right thing would be to implement the OPTIONAL part.  I don't know if I
will have time for this before 2.8 (patches are welcome...).

With regard to the differences between the good cmake results on the one
hand and the bad ccmake and cmake-gui results on on the other hand for my
simple but nonstandard example, I agree that CMake language support is sort
of a "magical" area of CMake so it is perhaps not too surprising that using
it in this unanticipated way exposes differences between the various cmake
applications. So given your time constraints you may want to just cross your
fingers and let this exposed issue slide.

However, that exposed issue was discovered because I needed a workaround for
bug 9220 so I agree the fundamental thing to do would be to deal with bug
9220.


On 2009-07-16 14:12-0400 Bill Hoffman wrote:

David Cole wrote:
Another work around might be doing an execute_process with another CMake that processes a one-line file with an enable_language call in it... If it fails to configure, the caller of execute_process could fail gracefully rather than with the hard error that an enable_language call currently gives. And if it succeeds, then presumably it would be safe to call enable_language for that language... You'd have to use your own variables to track with this technique and not rely on the built-in ones.


That is a good idea, and it would work with any version of cmake.

Hi David:

I think you inadvertently posted your comment off list so I hope you don't
mind if I quote you (and also Bill's response to your idea) on list.

Thanks for that good idea for a temporary workaround to bug 9220. Your idea
even takes care of the broken compiler case.  (My attempted workaround only
took care of the missing compiler case.) I will implement that workaround
for now for the PLplot build system, but that's a little complicated for
most projects that want to implement a soft landing when compilers are
missing/broken.  So fixing bug 9220 is obviously the best long-term
solution.


I agree. Fixing bug 9220 is the best solution.

I replied directly to you and Bill because I thought it would be a good idea to try it out first before posting to the list... and I did not have time to try it, but I thought maybe you would.

At any rate, I do not consider anything I say through email to be "private" in any sense, so I do not mind you quoting me. :-)

Hope it works as a work-around for now.

David


_______________________________________________
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
|  
Report Content as Inappropriate

Re: cmake-gui leaves CMAKE_<language>_COMPILER_WORKS undefined for simple test case and CMake-2.6.4

Alan W. Irwin
In reply to this post by Alan W. Irwin
On 2009-07-16 13:23-0700 Alan W. Irwin wrote:

> Hi David:
>
> [...] Your idea (for temporarily working around bug 9220)
> even takes care of the broken compiler case.  (My attempted workaround only
> took care of the missing compiler case.) I will implement that workaround
> for now for the PLplot build system [....]

For those following this thread, here is my first implementation of your
idea for this workaround.  When I uncommented the tests, I got

CXX_language_works = ON
CXXp_language_works = OFF

as expected.

*********
# cmake/modules/language_support.cmake
#
# Temporary additional general language support is contained within this
# file.

# This additional function definition is needed to provide a workaround for
# CMake bug 9220.

function(workaround_9220 language language_works)
   #message("DEBUG: language = ${language}")
   set(text
     "project(test NONE)
cmake_minimum_required(VERSION 2.6.0)
enable_language(${language} OPTIONAL)
"
     )
   file(REMOVE_RECURSE ${CMAKE_BINARY_DIR}/language_tests/${language})
   file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/language_tests/${language})
   file(WRITE ${CMAKE_BINARY_DIR}/language_tests/${language}/CMakeLists.txt
     ${text})
   execute_process(
     COMMAND ${CMAKE_COMMAND} .
     WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/language_tests/${language}
     RESULT_VARIABLE return_code
     OUTPUT_QUIET
     ERROR_QUIET)
   if(return_code EQUAL 0)
     set(${language_works} ON PARENT_SCOPE)
   else(return_code EQUAL 0)
     set(${language_works} OFF PARENT_SCOPE)
   endif(return_code EQUAL 0)
endfunction(workaround_9220)

# Temporary tests of the above function.
#workaround_9220(CXX CXX_language_works)
#message("CXX_language_works = ${CXX_language_works}")
#workaround_9220(CXXp CXXp_language_works)
#message("CXXp_language_works = ${CXXp_language_works}")
*********

I hope this file (which I have also attached to bug 9220) will help someone
else looking for a workaround for the bug.

I now have further work to do to add copying of local language support files
when the language is Ada or D, but this first implementation that works both
for CXX (a.k.a C++) and the non-existing language CXXp shows I am well on
the way to a good general bug 9220 workaround for PLplot. I am looking
forward to giving our users a soft landing for the case where some of the
five compilers that can optionally be used to build various PLplot
components are broken or non-existent on their systems.

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
Loading...