[CMake] CMake 2.8.7-rc2 ready for testing!

David Cole david.cole at kitware.com
Thu Dec 29 22:59:10 EST 2011


On Thu, Dec 29, 2011 at 9:15 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca>wrote:

> On 2011-12-29 18:34-0500 David Cole wrote:
>
>  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.
>>
>
> Hi Dave:
>
> I was surprised you didn't take the conservative course here since
> that is the CMake tradition for dealing with regressions, and the find
> modules for lapack/blas are dealing with a particularly complicated
> lapack/blas ecosystem where it is easy for these find modules to go wrong
> for some platforms.  However, I also recognize that this is your
> judgement call to make, and I do hope that you are correct that the
> benefit of these post-2.8.5 changes is really worth the cost of the
> lapack/blas library inconsistency regression that was introduced by
> the changes.
>
> I will try to come up with a fix for the regression early in the next
> release cycle and run it by the lapack/blas find module maintainer,
> Alexey Ozeritsky.
>
>
> 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
> __________________________
>


There is no conservative course here. There is a choice of whether to make
CMake 2.8.7 behave the same as 2.8.6 or the same as 2.8.5.

For this to be a showstopper it would have had to be reported before we
tagged 2.8.6 -- since it is now already in 2.8.6, it should simply be
considered a bug that we will try to address as soon as possible and get it
merged into master in time for the following release.

It would also be nice if this were more than simply a back-and-forth
discussion between you and I. I would sure appreciate more input from other
LAPACK and BLAS clients. I will take this as a personal lesson not to
schedule a release of any kind the week in between Christmas and New
Year's. If we stick to our schedule throughout the coming year, I'll make
sure that the December release of CMake next year is well *before*
Christmas.


Thanks,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111229/614d7ab4/attachment.htm>


More information about the CMake mailing list