[CMake] CMake 2.8.7-rc2 ready for testing!

[David Cole]

On Tue, Dec 27, 2011 at 3:34 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca>wrote:

> 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<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
> __________________________
>


I've considered your plea, but after looking at the diffs between 2.8.5 and
2.8.7-rc2, I think we ought to keep what we have and continue moving
forward with it.

The commits involved are easily seen with these git commands:

$ gitk v2.8.5..a1c9de56 -- Modules/FindLAPACK.cmake Modules/FindBLAS.cmake

$ git log --oneline v2.8.5..a1c9de56 -- Modules/FindLAPACK.cmake
Modules/FindBLAS.cmake

b3c42cb FindLAPACK: List thread libs to avoid link errors (#12625)
f603cf2 FindLAPACK: Correct CMAKE_FIND_LIBRARY_SUFFIXES spelling (#12624)
f44f053 FindLAPACK: Fix linking to static LAPACK on Unix (#12477)
0cc8f05 FindBLAS/LAPACK fixes
145de0a FindBLAS/LAPACK fixes
cfad24a fixed: search of ATLAS library for C/C++-only projects
d5e6030 ACML-GPU supportede
af4c58b ACML-GPU supported
91b76e2 gotoblas supported
66a4bd0 fixed: search of acml libraries

I think the fixes that these commits represent outweigh the issue you've
raised here late in the game. Especially since 7 of those commits are
already in the 2.8.6 release.

It would be good for you, perhaps, to communicate directly with the
FindLAPACK module maintainer. His email is listed on the module maintainers
page: http://www.cmake.org/Wiki/CMake:Module_Maintainers

Find module changes are a difficult beast to vet thoroughly, especially
when they involve more than one Find module, since there are infinite
combinations of packages in the real world.

If anybody disagrees with this decision, please reply and voice your
additional concerns. But unless you have a compelling argument to revert 10
commits in favor of 1 new complaint, I'll be kicking off the build of the
official 2.8.7 release tomorrow morning.


Thanks,
David Cole
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111229/d6a75184/attachment-0001.htm>