The script to make f90depends is broken. It could be fixed. But I just do
parallel makes on my machine and fix it manually. It takes about 5 minutes
once you have the build itself below 1 minute.
I maintain decoupling PMEMD from the rest of AmberTools solves my personal
problem to the point I might even enable a bespoke PMEMD cmake to keep up
with the cool kids.
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.
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
Received on Mon Apr 05 2021 - 11:30:03 PDT
