[CMake] CMake 2.8.7-rc2 ready for testing!

[Alan W. Irwin]

On 2011-12-21 20:42-0500 David Cole wrote:

> The CMake 2.8.7 release candidate stream continues! You can find the
> source and binaries here:
>
>  http://www.cmake.org/files/v2.8/?C=M;O=D
>
> This will become the final build of CMake 2.8.7 next Wednesday unless
> somebody finds and reports a showstopping (crasher, serious behavioral
> regression) issue between now and then.

Hi Dave:

Sorry for responding so late for your call for testing. A simple test
I did for PLplot seems fine, but from an additional test with FreeEOS
I just discovered there is still a potentially nasty regression for
FindLAPACK.cmake/FindBLAS.cmake from the good behavour we had for
2.8.5.

The issue is that if I set CMAKE_LIBRARY_PATH to find a special
version of lapack/blas, only the lapack part of that is honored.  For
example, if I set

export CMAKE_LIBRARY_PATH=/home/software/lapack/install_double/lib

Then here are the relevant cache results for 2.8.7

irwin at raven> grep BLAS CMakeCache.txt |grep -v ADV |grep -v NOTFOUND
BLAS_atlas_LIBRARY:FILEPATH=/usr/lib/libatlas.so.3gf
BLAS_f77blas_LIBRARY:FILEPATH=/usr/lib/libf77blas.so.3gf
BLAS_f77blas_atlas_WORKS:INTERNAL=1
irwin at raven> grep LAPACK CMakeCache.txt |grep -v ADV | grep -v NOTFOUND
LAPACK_lapack_LIBRARY:FILEPATH=/home/software/lapack/install_double/lib/liblapack.a
LAPACK_lapack_WORKS:INTERNAL=1

The resulting LAPACK_LIBRARIES uncached variable is

LAPACK_LIBRARIES =
/home/software/lapack/install_double/lib/liblapack.a;/usr/lib/libf77blas.so.3gf;/usr/lib/libatlas.so.3gf

i.e., a mixture between the very latest lapack results and older
system version blas results that I don't want. This inconsistent
mixture of libraries (which are for different versions of lapack/blas
and probably different compile flags as well) potentially could be a
complete disaster.  This odd combination of libraries actually worked
for my particular (FreeEOS) case, but I think that might be an
artifact of building and installing only static versions of
lapack/blas in the CMAKE_LIBRARY_PATH location.

In comparison here are the relevant cache results for 2.8.5

irwin at raven> grep BLAS CMakeCache.txt |grep -v ADV |grep -v NOTFOUND
BLAS_blas_LIBRARY:FILEPATH=/home/software/lapack/install_double/lib/libblas.a
BLAS_blas_WORKS:INTERNAL=1
irwin at raven> grep LAPACK CMakeCache.txt |grep -v ADV |grep -v NOTFOUND
LAPACK_lapack_LIBRARY:FILEPATH=/home/software/lapack/install_double/lib/liblapack.a
LAPACK_lapack_WORKS:INTERNAL=1

The resulting LAPACK_LIBRARIES uncached variable is

LAPACK_LIBRARIES =
/home/software/lapack/install_double/lib/liblapack.a;/home/software/lapack/install_double/lib/libblas.a

which is exactly what I want, i.e., no chance for inconsistency
between lapack and blas libraries.

There is probably some quick fix you can do to get FindBLAS.cmake to
properly honor CMAKE_LIBRARY_PATH, but since it is so late in the
release cycle there is not much chance to test such a change.  Note an
extreme degree of caution is warranted for changes in
FindLAPACK.cmake/FindBLAS.cmake because there are so many different
variants of those libraries available on various platforms.
Furthermore, the new versions of FindLAPACK.cmake/FindBLAS.cmake that
were introduced for 2.8.6 have already had two bugs fixed, with this
additional library inconsistency issue still to be fixed.  So these
new versions of the find modules don't appear to be completely matured
yet, and my recommendation would therefore be to revert back to the
time-tested versions of FindLAPACK.cmake/FindBLAS.cmake for 2.8.5 for
your 2.8.7 release, and re-introduce the new (with all known issues
fixed) versions of these modules for the next release cycle to give
them some additional testing before the next release.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__________________________