Re: [AMBER-Developers] CMake vs configure2 in Amber

From: Daniel Roe <daniel.r.roe.gmail.com>
Date: Mon, 5 Apr 2021 14:42:56 -0400

On Mon, Apr 5, 2021 at 2:29 PM Scott Le Grand <varelse2005.gmail.com> wrote:
>
> And while rewriting in C/C++ sounds cool a priori, and in fact I did that
> as a grad student back in 1991 so I know it's not hard, I like that F90
> keeps scientists away from the greasy kids stuff of C++14 and beyond. I
> mean you guys had C++11 support and you *still* added boost to PMEMD. Sad.

Just rewrite pmemd as a library so I can call it from cpptraj :-)
(j/k, mostly...)

>
> On Mon, Apr 5, 2021 at 11:24 AM Daniel Roe <daniel.r.roe.gmail.com> wrote:
>
> > Hi,
> >
> > On Sun, Apr 4, 2021 at 8:34 PM Gerald Monard <gerald.monard.gmail.com>
> > wrote:
> > > - parallel make works! There are been many cases of incorrect parallel
> > > building with the conventional/legacy configure+Makefile script due to
> > > weird/unchecked dependencies
> >
> > FYI, this is not always true. I just hit a build failure with CMAKE
> > using 'make -j4' that was resolved with using plain 'make':
> >
> > ```
> > cifparse.y: warning: fix-its can be applied. Rerun with option
> > '--update'. [-Wother]
> > In file included from BLAS_error.c:5:0:
> > ../blas_extended.h:7:10: fatal error: blas_extended_proto.h: No such
> > file or directory
> > #include "blas_extended_proto.h"
> > ^~~~~~~~~~~~~~~~~~~~~~~
> > compilation terminated.
> > make[4]: *** [Makefile:19: BLAS_error.o] Error 1
> > make[3]: *** [Makefile:101: common-lib] Error 2
> > make[3]: *** Waiting for unfinished jobs....
> > ```
> >
> > Seems to be an XBLAS issue. I don't necessarily blame cmake tho - with
> > a build as complex as Amber, it's not surprising that things like this
> > happen.
> >
> > -Dan
> >
> >
> > > - don't need to rebuild sander 4 times when you changed 1 file (sander,
> > > sander.LES, sander.XXX, sander.YYY etc.)
> > >
> > > Gerald.
> > >
> > > On Mon, Apr 5, 2021 at 6:33 AM Scott Le Grand <varelse2005.gmail.com>
> > wrote:
> > >
> > > > Cmake (IMO and entirely IMO) is great if you have someone full-time to
> > > > maintain it. If we are willing to invest those resources, great, then
> > cmake
> > > > issues are on cmake person and they get to own it going forward.
> > Trying to
> > > > offload this onto the AMBER community will ensue hilarity
> > > > #HearMeNowBelieveMeLater
> > > >
> > > > I'm all for new ideas, but I'm against new ideas without funding and
> > > > commitment.
> > > >
> > > > Scott
> > > >
> > > >
> > > >
> > > > On Sun, Apr 4, 2021 at 2:26 PM Scott Brozell <sbrozell.comcast.net>
> > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > New subject to get back to the main thread.
> > > > >
> > > > > On Sun, Apr 04, 2021 at 08:51:00AM -0400, David A Case wrote:
> > > > > > On Sat, Apr 03, 2021, Scott Le Grand wrote:
> > > > > >
> > > > > > >cmake is still not quite ready for prime time disruption of
> > configure.
> > > > > It's
> > > > > > >getting there though.
> > > > > >
> > > > > > If there are problems with cmake, please create an issue on
> > gitlab, and
> > > > > > mention .multiplemonomials to get Jamie's attention. Please try to
> > > > avoid
> > > > > > the syndrome of saying "I can get this to work with configure, and
> > I'm
> > > > to
> > > > > > busy right now to do anything else."
> > > > > >
> > > > > > I have removed the documentation for the configure process in the
> > > > Amber21
> > > > > > Reference Manual, although the files are still present. We can't
> > > > > continue
> > > > > > to support and test two separate build systems, each with their own
> > > > bugs.
> > > > >
> > > > > The evidence supports that legacy configure is easier to maintain and
> > > > > extend.
> > > > >
> > > > > This may be a somewhat surprising result given the sprawl of
> > configure2,
> > > > > but since developers are script writers it is straightforward for
> > them
> > > > > to examine configure2 with eyeballs or grep and figure out what needs
> > > > > to happen to support something new or fix something broken.
> > > > >
> > > > > In contrast cmake complicates simple grepping and spreads building
> > over
> > > > > many files; approximately 211 of them presently. In addition, cmake
> > > > > expertise in our group is limited, to approximately 1 person based on
> > > > > Dave's comment above.
> > > > >
> > > > > The evidence is plentiful; here are some very recent ones:
> > > > > The evidence includes merge 827 and temporally close MRs, where cmake
> > > > > didnt build reaxff_puremd (and so CI on reaxff_puremd has been turned
> > > > off)
> > > > > but legacy configure builds reaxff_puremd fine; similar story for
> > > > pbsa.cuda
> > > > > where cmake fails and legacy configure works.
> > > > > In addition, there are a number of cmake quirks/gotchas reported by
> > me
> > > > > in the testing wiki.
> > > > >
> > > > > scott
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > AMBER-Developers mailing list
> > > > > AMBER-Developers.ambermd.org
> > > > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > > > >
> > > > _______________________________________________
> > > > AMBER-Developers mailing list
> > > > AMBER-Developers.ambermd.org
> > > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > > >
> > > _______________________________________________
> > > AMBER-Developers mailing list
> > > AMBER-Developers.ambermd.org
> > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> >
> > _______________________________________________
> > AMBER-Developers mailing list
> > AMBER-Developers.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber-developers
> >
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers

_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Apr 05 2021 - 12:00:04 PDT
Custom Search