<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 19, 2013 at 12:20 AM, Szilárd Páll <span dir="ltr"><<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, Jun 18, 2013 at 7:15 PM, Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Tue, Jun 18, 2013 at 6:47 PM, Roland Schulz <<a href="mailto:roland@utk.edu">roland@utk.edu</a>> wrote:<br>
>><br>
>> On Tue, Jun 18, 2013 at 11:05 AM, Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>><br>
>> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Mon, Jun 17, 2013 at 7:59 PM, Roland Schulz <<a href="mailto:roland@utk.edu">roland@utk.edu</a>> wrote:<br>
>> >><br>
>> >> On Mon, Jun 17, 2013 at 1:10 PM, Mark Abraham<br>
>> >> <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>><br>
>> >> wrote:<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > On Mon, Jun 17, 2013 at 6:16 PM, Manuel Nuno Melo <<a href="mailto:m.n.melo@rug.nl">m.n.melo@rug.nl</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> Hi,<br>
>> >> >><br>
>> >> >> I have also had linking problems when making in parallel. In my case<br>
>> >> >> they<br>
>> >> >> could be traced back to the option to let GMX download/build its own<br>
>> >> >> fftw<br>
>> >> >> (-DGMX_BUILD_OWN_FFTW=ON).<br>
>> >> >><br>
>> >> >> It seems that only one of make's threads starts building fftw, while<br>
>> >> >> the<br>
>> >> >> others go ahead building/linking GMX. Since fftw compilation is not<br>
>> >> >> ready by<br>
>> >> >> the time it is needed, GMX linking is botched.<br>
>> >> ><br>
>> >> ><br>
>> >> > Yes, Rossen first showed this to me. I don't know if the underlying<br>
>> >> > issue is<br>
>> >> > that the dependency cannot be described properly, or that we're not<br>
>> >> > doing it<br>
>> >> > properly. If it's a problem, people are welcome to contribute a fix!<br>
>> >> > :-)<br>
>> >> It was working in <a href="https://gerrit.gromacs.org/#/c/1675/12" target="_blank">https://gerrit.gromacs.org/#/c/1675/12</a>. You then<br>
>> >> changed how the dependency works in patch set 13. You never replied to<br>
>> >> Christophs comment why this was changed (at least I can't find a<br>
>> >> reply). Do you remember?<br>
>> ><br>
>> ><br>
>> > I couldn't remember, but gerrit can - I never published a series of<br>
>> > responses I made back then, sorry. Now published at<br>
>> > <a href="https://gerrit.gromacs.org/1675" target="_blank">https://gerrit.gromacs.org/1675</a><br>
>> ><br>
>> >> Otherwise I can change it back as 12 did it<br>
>> >> and it should work again.<br>
>> ><br>
>> ><br>
>> > It might do, but as I said in those secret drafts the form of patch 12<br>
>> > doesn't work on cmake 2.8.7 because of a bug there in<br>
>> > add_library(...GLOBAL)<br>
>> > (and I suspect is probably too global, anyway, but this probably does no<br>
>> > harm?).<br>
>> ><br>
>> > So I'm still not sure there's a convenient solution that works in all<br>
>> > cases.<br>
>> > Compromising the smooth running of a parallel make for someone<br>
>> > downloading<br>
>> > FFTW seems like the most low-impact problem of the set we could choose<br>
>> > to<br>
>> > have.<br>
>><br>
>> Probably true. Just doesn't give a good first impression of us to new<br>
>> users.<br>
>> I think we should also consider for the future whether we really want<br>
>> to support ~11 unmaintained version of cmake (including for all our<br>
>> optional features). Downloading cmake is no big deal. They have<br>
>> binaries to download. And cmake doesn't fix any version but for the<br>
>> most recent version. So it seems odd that we try to maintain<br>
>> workarounds for the last ~11 versions which are all unmaintained by<br>
>> the cmake developers. That seems like it is going to stay a really<br>
>> annoying maintenance task.<br>
><br>
><br>
> True. Now that we've shown it is a PITA for the developers to work around a<br>
> handful of known issues with various 2.8.x point releases of CMake, it<br>
> sounds reasonable to me that we pick a late-model CMake 2.8.x as the<br>
> requirement for GROMACS 5. That could open the door to an alternative<br>
> implementation for self-built FFTW.<br>
<br>
</div></div>I agree that it is annoying having to work around CMake issues. At the<br>
same time, I think it would be a rather "user-unfriendly" move to<br>
require a very late version of CMake. As a user, it is fair to expect<br>
that building GROMACS is as hassle-free as possible.</blockquote><div><br></div><div style>Right. But I think all of the CMake issues have arisen while trying to make building GROMACS as hassle-free as possible. Here are just some of the known issues:</div>
<div style>1) we need something in 2.8.2 in order to download the regression tests via CMake</div><div style>2) 2.8.10 updated FindCUDA and changed the behaviour with respect to setting the host compiler for nvcc</div><div style>
3) 2.8.8 provides CMAKE_<LANG>_COMPILER_VERSION, for which we currently provide duplicate functionality in at least two places; this is mostly used for supporting tests for known versions of compilers that have missing or broken functionality</div>
<div style>4) we sometimes fall back on finding MPI, which didn't work well before 2.8.5 (and find_file() has a minor bug that was fixed in 2.8.10)</div><div style>5) can't check an MD5 sum of the downloaded FFTW library before 2.8.3</div>
<div style>6) one way to link the downloaded FFTW library doesn't work on 2.8.7</div><div style>Those are all things that we are trying to do to make a hassle-free GROMACS build experience. In some of the above cases we issue a fatal error and suggest a CMake upgrade anyway.</div>
<div style><br></div><div style>The principle has led the GROMACS devs to do a whole pile of "extra" work implementing those checks, and future work reading and maintaining that code. This is not sustainable. For GROMACS 4.6, we compromised on CMake 2.8 between developer convenience and the possibility users would not need to install cmake, which we did before realising we'd be encouraging about half the users to update to a real compiler. Getting cmake at the same time is not a big deal. Requiring 2.8.10 for GROMACS 5 lets get rid of a lot of nonsense and go back to writing MD code.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hence, having to<br>
download CMake as a first step of the installation process will<br>
probably lead to many users not updating (early) to newer GROMACS<br>
versions.<br></blockquote><div><br></div><div style>I'd much rather spend devs time writing documentation of their awesome new features, so that users know they can do cool science with the new version if they get a new CMake version (which they might re-use anyway). The needs of the few and the needs of the many are being traded off here. It's not like we're charging money selling shrink-wrapped software. :-)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In general, the issue is the way CMake development introduces changes<br>
in minor versions which affect behaviour. This can easily break<br>
fragile code in the build system. I don't have a good suggestion to<br>
overcome such problems, but I think that the choice of required<br>
minimum CMake version should depend on what versions provide the major<br>
Linux OS-es.<br></blockquote><div><br></div><div style>RHEL ships with a 2.6 (which drives CentOS and Scientific Linux). EPEL provides a 2.8.9, though.</div><div style>Current Ubuntu LTS (precise) has 2.8.7, but the next looks like it would have at least 2.8.11. Current stable has 2.8.10.</div>
<div style>Fedora 19 has 2.8.10.</div><div style>macports has 2.8.10</div><div style><br></div><div style>So it seems to me that requiring CMake 2.8.10 for a Feb 2014 release is quite reasonable.</div><div style><br></div>
<div style>Mark</div></div></div></div>