On 2009-06-28 19:08-0700 Alan W. Irwin wrote:
> [...]My method of recovery in case of a bad compiler
> (disabling the appropriate bindings/examples) normally should work. However,
> my light testing was done for a platform with working Ada, C, C++, D,
> Fortran, and Java compilers so my method of recovery has not actually been
> tested.
>
> Geoffrey, as a first test of recovery will you test that these changes allow
> you to build PLplot without specifying -DENABLE_ada=OFF for your F11 system
> which appears to have a broken Ada compiler?
Geoffrey responded off list with the bad news that this OPTIONAL idea did
not work for Ada. I then got a lot smarter and figured out how to emulate a
bad compiler by e.g., "FC='gfortran whatever' cmake ..." where the
non-existing "whatever" file kills off the try_compile command which tests
the given compiler and which therefore exercises the recovery method for
PLplot.
Using such tests on the new build system for the installed examples (where
as of revision 10095 I also installed OPTIONAL language support), I
confirmed Geoffrey's result not only for Ada, but for every other compiler
we use (sigh). I then tried a really simple CMakeLists.txt file
cmake_minimum_required(VERSION 2.6.4)
project(test NONE)
enable_language(Fortran OPTIONAL)
message(STATUS "CMAKE_FORTRAN_COMPILER_WORKS = ${CMAKE_Fortran_COMPILER_WORKS}")
and got the same bad result (cmake quits with an error message for bad
compilers rather than returning control properly to the CMakeLists.txt where
the CMAKE_<language>_COMPILER_WORKS variable can be used to deal with the
issue). This issue got at least a small amount of attention from a CMake
developer on the CMake mailing list so following his instructions I have
reported this as a CMake bug at
http://public.kitware.com/Bug/view.php?id=9220.
It will obviously take a while for CMake developers to deal with this issue
so for the immediate future neither our core build system nor our new build
system for the installed examples will recover smoothly (by eliminating the
appropriate component of PLplot with a warning message and continuing) if
there exists a bad compiler that fails to pass the try_compile test.
For the case of a missing compiler (which should also be taken care of by
OPTIONAL once the CMake developers fix the bug), I have uniformly
implemented a workaround of searching for the compiler _before_ enabling the
language. (That workaround was used for at least some languages previously
to my last commit that eliminated it because I erroneously didn't think we
would need it anymore). Revision 10096 (which also contains the equivalent
fix for the new build system for installed examples) implements this
workaround for all our compiled languages.
It turns out another aspect of the above CMake bug is cmake errors out if
you specify a non-existing compiler with the CC, etc., environment
variables. So I tested revision 10096 by a different method which consisted
of systematically moving gcc, g++, gdc, gfortran, gnatgcc to a temporary
name. Under these conditions the new build system seems to work well (gives
a smooth recovery) for the installed examples in all but the Ada case (which
appears to be ideosyncratic since it shifts to trying gcc if gnatgcc is
unavailable).
So revision 10096 should deal with the missing compiler case in a smooth way
(except for Ada), but we are absolutely stuck with abrupt erroring out for
the bad compiler case until the CMake developers can come up with a fix to
bug 9220.
Geoffrey has told me off list that he is now reasonably satisfied. The other
build issues (qt, etc.,) that he was encountering have now been solved by my
other recent commits so he can continue his PLplot development work by
simply disabling Ada on Fedora 11.
Geoffrey has been a hard taskmaster for the build system, and I am sure that
will continue. However, I strongly encourage that. After all, it is only
fair because my testing activities reveal PLplot run-time bugs (segfaults,
memory management issues, etc.,) that make me a hard taskmaster for the C
and C++ experts here. Also, of course, having hard taskmasters on the
development team is fundamentally useful because it means we discover and
fix problems that were probably discouraging some of our users who didn't
have the confidence/expertise to report the issues to us.
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
__________________________
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
