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
Received on Sun Apr 04 2021 - 14:30:02 PDT
