HI,
I agree that cmake should be maintained by more than 1 person, and that,
for people not versed into cmake, the configure script is easier to modify.
BUT, imho:
- cmake actually provides a clearer way to build the software suite: you
can build the full suite with 1 cmake configuration (and 1 build pass)
instead of running several configures for serial/openmp/cuda serial/cuda
mpi/mpi/ etc.
- the build directory is separated from the source code, which is great,
especially when you use the source for different usage (i.e., for me, when
using containers and different OSes, compilers, etc.), it's even greater
when you build serial+openmp+mpi all at once, because you never know if
your object files buried into the source code trees are
serial/parallel/openmp with the legacy configuration/build mechanism
- parallel make works! There are been many cases of incorrect parallel
building with the conventional/legacy configure+Makefile script due to
weird/unchecked dependencies
- 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
Received on Sun Apr 04 2021 - 18:00:02 PDT
