<div class="gmail_quote">On Tue, Dec 27, 2011 at 3:34 PM, Alan W. Irwin <span dir="ltr"><<a href="mailto:irwin@beluga.phys.uvic.ca">irwin@beluga.phys.uvic.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2011-12-21 20:42-0500 David Cole wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The CMake 2.8.7 release candidate stream continues! You can find the<br>
source and binaries here:<br>
<br>
<a href="http://www.cmake.org/files/v2.8/?C=M;O=D" target="_blank">http://www.cmake.org/files/v2.<u></u>8/?C=M;O=D</a><br>
<br>
This will become the final build of CMake 2.8.7 next Wednesday unless<br>
somebody finds and reports a showstopping (crasher, serious behavioral<br>
regression) issue between now and then.<br>
</blockquote>
<br></div>
Hi Dave:<br>
<br>
Sorry for responding so late for your call for testing. A simple test<br>
I did for PLplot seems fine, but from an additional test with FreeEOS<br>
I just discovered there is still a potentially nasty regression for<br>
FindLAPACK.cmake/FindBLAS.<u></u>cmake from the good behavour we had for<br>
2.8.5.<br>
<br>
The issue is that if I set CMAKE_LIBRARY_PATH to find a special<br>
version of lapack/blas, only the lapack part of that is honored. For<br>
example, if I set<br>
<br>
export CMAKE_LIBRARY_PATH=/home/<u></u>software/lapack/install_<u></u>double/lib<br>
<br>
Then here are the relevant cache results for 2.8.7<br>
<br>
irwin@raven> grep BLAS CMakeCache.txt |grep -v ADV |grep -v NOTFOUND<br>
BLAS_atlas_LIBRARY:FILEPATH=/<u></u>usr/lib/libatlas.so.3gf<br>
BLAS_f77blas_LIBRARY:FILEPATH=<u></u>/usr/lib/libf77blas.so.3gf<br>
BLAS_f77blas_atlas_WORKS:<u></u>INTERNAL=1<br>
irwin@raven> grep LAPACK CMakeCache.txt |grep -v ADV | grep -v NOTFOUND<br>
LAPACK_lapack_LIBRARY:<u></u>FILEPATH=/home/software/<u></u>lapack/install_double/lib/<u></u>liblapack.a<br>
LAPACK_lapack_WORKS:INTERNAL=1<br>
<br>
The resulting LAPACK_LIBRARIES uncached variable is<br>
<br>
LAPACK_LIBRARIES =<br>
/home/software/lapack/install_<u></u>double/lib/liblapack.a;/usr/<u></u>lib/libf77blas.so.3gf;/usr/<u></u>lib/libatlas.so.3gf<br>
<br>
i.e., a mixture between the very latest lapack results and older<br>
system version blas results that I don't want. This inconsistent<br>
mixture of libraries (which are for different versions of lapack/blas<br>
and probably different compile flags as well) potentially could be a<br>
complete disaster. This odd combination of libraries actually worked<br>
for my particular (FreeEOS) case, but I think that might be an<br>
artifact of building and installing only static versions of<br>
lapack/blas in the CMAKE_LIBRARY_PATH location.<br>
<br>
In comparison here are the relevant cache results for 2.8.5<br>
<br>
irwin@raven> grep BLAS CMakeCache.txt |grep -v ADV |grep -v NOTFOUND<br>
BLAS_blas_LIBRARY:FILEPATH=/<u></u>home/software/lapack/install_<u></u>double/lib/libblas.a<br>
BLAS_blas_WORKS:INTERNAL=1<br>
irwin@raven> grep LAPACK CMakeCache.txt |grep -v ADV |grep -v NOTFOUND<br>
LAPACK_lapack_LIBRARY:<u></u>FILEPATH=/home/software/<u></u>lapack/install_double/lib/<u></u>liblapack.a<br>
LAPACK_lapack_WORKS:INTERNAL=1<br>
<br>
The resulting LAPACK_LIBRARIES uncached variable is<br>
<br>
LAPACK_LIBRARIES =<br>
/home/software/lapack/install_<u></u>double/lib/liblapack.a;/home/<u></u>software/lapack/install_<u></u>double/lib/libblas.a<br>
<br>
which is exactly what I want, i.e., no chance for inconsistency<br>
between lapack and blas libraries.<br>
<br>
There is probably some quick fix you can do to get FindBLAS.cmake to<br>
properly honor CMAKE_LIBRARY_PATH, but since it is so late in the<br>
release cycle there is not much chance to test such a change. Note an<br>
extreme degree of caution is warranted for changes in<br>
FindLAPACK.cmake/FindBLAS.<u></u>cmake because there are so many different<br>
variants of those libraries available on various platforms.<br>
Furthermore, the new versions of FindLAPACK.cmake/FindBLAS.<u></u>cmake that<br>
were introduced for 2.8.6 have already had two bugs fixed, with this<br>
additional library inconsistency issue still to be fixed. So these<br>
new versions of the find modules don't appear to be completely matured<br>
yet, and my recommendation would therefore be to revert back to the<br>
time-tested versions of FindLAPACK.cmake/FindBLAS.<u></u>cmake for 2.8.5 for<br>
your 2.8.7 release, and re-introduce the new (with all known issues<br>
fixed) versions of these modules for the next release cycle to give<br>
them some additional testing before the next release.<br>
<br>
Alan<br>
__________________________<br>
Alan W. Irwin<br>
<br>
Astronomical research affiliation with Department of Physics and Astronomy,<br>
University of Victoria (<a href="http://astrowww.phys.uvic.ca" target="_blank">astrowww.phys.uvic.ca</a>).<br>
<br>
Programming affiliations with the FreeEOS equation-of-state<br>
implementation for stellar interiors (<a href="http://freeeos.sf.net" target="_blank">freeeos.sf.net</a>); the Time<br>
Ephemerides project (<a href="http://timeephem.sf.net" target="_blank">timeephem.sf.net</a>); PLplot scientific plotting<br>
software package (<a href="http://plplot.sf.net" target="_blank">plplot.sf.net</a>); the libLASi project<br>
(<a href="http://unifont.org/lasi" target="_blank">unifont.org/lasi</a>); the Loads of Linux Links project (<a href="http://loll.sf.net" target="_blank">loll.sf.net</a>);<br>
and the Linux Brochure Project (<a href="http://lbproject.sf.net" target="_blank">lbproject.sf.net</a>).<br>
__________________________<br>
<br>
Linux-powered Science<br>
__________________________<br>
</blockquote></div><div><br></div><br><div>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.</div><div><br>
</div><div>The commits involved are easily seen with these git commands:</div><div><div><br></div><div>$ gitk v2.8.5..a1c9de56 -- Modules/FindLAPACK.cmake Modules/FindBLAS.cmake </div><div><br></div><div>$ git log --oneline v2.8.5..a1c9de56 -- Modules/FindLAPACK.cmake Modules/FindBLAS.cmake </div>
<div><br></div><div>b3c42cb FindLAPACK: List thread libs to avoid link errors (#12625)</div><div>f603cf2 FindLAPACK: Correct CMAKE_FIND_LIBRARY_SUFFIXES spelling (#12624)</div><div>f44f053 FindLAPACK: Fix linking to static LAPACK on Unix (#12477)</div>
<div>0cc8f05 FindBLAS/LAPACK fixes</div><div>145de0a FindBLAS/LAPACK fixes</div><div>cfad24a fixed: search of ATLAS library for C/C++-only projects</div><div>d5e6030 ACML-GPU supportede</div><div>af4c58b ACML-GPU supported</div>
<div>91b76e2 gotoblas supported</div><div>66a4bd0 fixed: search of acml libraries</div></div><div><br></div><div>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.</div>
<div><br></div><div>It would be good for you, perhaps, to communicate directly with the FindLAPACK module maintainer. His email is listed on the module maintainers page: <a href="http://www.cmake.org/Wiki/CMake:Module_Maintainers">http://www.cmake.org/Wiki/CMake:Module_Maintainers</a></div>
<div><br></div><div>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.</div><div><br></div>
<div>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.</div>
<div><br></div><div><br></div><div>Thanks,</div><div>David Cole</div><div>Kitware, Inc.</div><div><br></div>