So I think the real problem is that a relatively uncomplicated build like
PMEMD gets packaged into the AmberTools build along with everything else.
And something somewhere in AmberTools is messed up, it takes PMEMD with it.
So I will take your suggestion to decouple PMEMD 2.0 entirely from that
build with its own cmake file that autodetects the toolkit etc. I can build
PMEMD in 56 seconds cold when I'm in a compile-link-debug loop. Not so much
the unaltered outputs of cmake and configure as they are.
On Sun, Apr 4, 2021 at 6:45 PM David A Case <david.case.rutgers.edu> wrote:
> 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Apr 04 2021 - 20:30:02 PDT
