[gmx-developers] parallel make problems

[Mark Abraham]

On Wed, Jun 19, 2013 at 9:13 PM, Szilárd Páll <szilard.pall at cbr.su.se> wrote:
> On Wed, Jun 19, 2013 at 7:12 PM, Roland Schulz <roland at utk.edu> wrote:
>> On Wed, Jun 19, 2013 at 8:32 AM, Mark Abraham <mark.j.abraham at gmail.com> wrote:
>>
>>> On Tue, Jun 18, 2013 at 8:16 PM, Marcus D. Hanwell
>>> <marcus.hanwell at kitware.com> wrote:
>>
>>>> The other alternative that would work reliably is to use CMake to
>>>> build FFTW (possibly creating the CMakeLists.txt files if they don't
>>>> already exist) and using add_subdirectory to bring this in as a normal
>>>> target. Something VTK does for many third party libraries for example,
>>>> but the burden of maintaining a secondary build system for a project
>>>> can be pretty high.
>>>
>>>
>>> Yeah :-)
>>
>> If this is maintained by a community of cmake users it might actually
>> be a viable solution. Someone already started it:
>> https://github.com/smanders/fftw-cmake
>
> Good find! I think this is the best solution.

We'll look forward to seeing your patches, then ;-)

>> On Wed, Jun 19, 2013 at 9:48 AM, Szilárd Páll <szilard.pall at cbr.su.se> wrote:
>>> I do agree with you to a fairly large extent. However, most of the
>>> above workarounds are meant to support non-essential features, so
>>> either a warning (e.g. "skipping consitency check because CMake
>>> version <2.8.X") or in other cases a fatal error (e.g. "Insufficient
>>> CMake version for feature X") would be just fine instead of *
>>> hardcoded* very recent required version which would prevent users from
>>> building even if they don't use the feature which requires a late
>>> CMake version. Regarding points 2 and 3, those are good examples of
>>> minor feature additions which we could have chosen to ignore and stick
>>> to the legacy behavior, but we did not.
>>
>> I think a huge advantage of requiring ~2.8.10 for 5.0 is that we have
>> way less combinations to tests. For optional features Jenkins doesn't
>> help, and having to test for things like the fftw-download >11
>> versions whether they all work correctly is a huge pain. Thus this
>> suggestion wouldn't help with reducing the testing work. One would
>> still need to test all versions to check whether they are working, so
>> that one could print the correct errors/warnings. So I prefer having
>> one common minimum required version for all of Gromacs cmake.
>
> There are so many "grey zones" in the build system that are currently
> not covered by tests and that will likely never be. All I am
> advocating is to put a less restrictive cmake_minimum_required() in
> the code, but e.g. not claim that <v2.8.10 will always work

If we did that, then the rider would be that no code changes have to
worry about 2.8.10 compatibility, even to the extent of writing nice
error handling. In turn, that just makes more work answering queries
from users who are confused about why something mysteriously breaks.
Minimum requirements make life easier on the developers.

> - AFAIK
> there's anyway never been a clear statement of what version of
> software dependencies are "made sure that work" and to what extent.

Yep, and supporting 11+ CMake versions will guarantee it never happens.

> I've seen overzealous software restrictions backfire and it would be
> good to avoid that, e.g. tons of users got annoyed by the lagging gcc
> support in CUDA and many (including me) simply edit the "offending"
> line of source code (in this case an #if GCC_VERSION > FOO) instead of
> complying with the restriction.

Installing a new version of CMake is in a totally different ballgame.
Kitware has a strong interest in keeping that process easy ;-) Any
CMake requirement GROMACS makes is not necessarily a one-time thing
for the user. Other software can use that CMake!

Mark

> --
> Szilárd
>
>> Roland
>>
>>
>> --
>> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
>> 865-241-1537, ORNL PO BOX 2008 MS6309
>> --
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use the
>> www interface or send it to gmx-developers-request at gromacs.org.
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.