On Sun, Apr 04, 2021, Scott Le Grand wrote:
>I'm open to someone convincing me cmake is better than the configure
>script, but no one has made that argument yet beyond "because cmake"...
Jamie's arguments on behalf of CMake are summarized here:
https://ambermd.org/pmwiki/pmwiki.php/Main/CMakeFeatures
(There are many other "CMake" pages on the Amber wiki that contain a
lot of helpful information, especially when problems arise.)
Here's my short list:
1. The "configure2" script is 4300 lines of shell script, written over
20 years, with outdated and inconsistent features. Fortran dependency
checking relies on a set of perl scripts that should be (but often are
not) updated whenever files are added or subtracted. I wrote much of
this stuff, so no one should think it is either bulletproof or elegant.
2. Using cmake gets us help from outsiders, especially Jamie Smith,
Jaime Rodriguez-Guerro and Simon Bray, who have done wonders in getting
AmberTools accepted into a wider community. Because we now have a
well-supported conda package, AmberTools is often getting used by
people who don't even know what it is, since it is a part of other
packages. This would not have happened if we didn't make efforts
to follow standards that the wider community is willing to work with
(for better or worse.) FWIW, AmberTools at conda-forge has seen
about 200,000 downloads, and is being used by a number of
influential projects.
3. When we need to provide a workaround, it is *far* simpler to ask users
to add something like '-DDISABLE_TOOLS="mdgx" or
-DFORCE_INTERNAL_LIBS="boost" to their cmake invocations, than it
is to try to provide a modified configure script, or to ask users to
edit a Makefile somewhere in the tree.
> we rushed it [cmake] to production
I don't agree here. CMake was introduced to developers in March of 2017,
and recommended to users as the default three years later, in 2020. It has
been used regularly for CI testing for two years, and by thousands of users
for a full year.
If you find a problem with CMake, please create an issue at gitlab. If it is
a problem with code that will be AmberTools21, this is a particularly good
time to do this, since we'd like to get as many things fixed as we can
before the release.
...thx...dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Apr 04 2021 - 19:00:03 PDT
