[gmx-developers] parallel make problems

Szilárd Páll szilard.pall at cbr.su.se
Wed Jun 19 21:13:54 CEST 2013

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.

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

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.


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

More information about the gromacs.org_gmx-developers mailing list