Re: [AMBER-Developers] need suggestions about Amber12 build/test procedure

From: Jason Swails <>
Date: Tue, 14 Feb 2012 14:40:32 -0500

On Tue, Feb 14, 2012 at 1:58 PM, B. Lachele Foley <> wrote:

> First thing:
> I want to compliment you all on the new build. It's easier by far, seems
> stabler, and is WAY faster. I swear the entire thing now takes half the
> time that AmberTools, alone, used to. Whatever it was you did, oh
> thankyouthankyouthankyou.

Out of curiosity, do you use parallel make? That shortens things
significantly for me. Tyler has been great in making sure "make -j" keeps
working despite all our abuses.

> Getting back to topic:
> The build process isn't terrible, but could it be collapsed for users who
> don't need special stuff? I'm thinking something along the lines of:
> ./configure -all -mpi gnu
> make install
> for folks without cuda, and
> ./configure -all -mpi -cuda gnu
> make install

This concept is attractive to me (I'd name the flags differently, but
that's irrelevant), but from a general usability perspective, I think we
should avoid this. This would add an MPI dependency (or complications) on
the serial build, and will take a non-negligible amount of re-working the
build procedure to accomplish (the current workflow is hard-wired in some
places). Therefore, I'll actually cast my vote against this
(unfortunately) for the official release. I think people should jump
through _some_ hoops for some advanced options (i.e., you really should
understand how to run the serial programs before getting into the parallel
programs). But it's still easy enough to be accessible. I also think it's
too close to release to be trying such a radical change for so limited
(IMO, of course) a return.

> for folks with cuda. The idea being it would go through the serial,
> parallel, etc., all in a row as usual, for folks who have standard needs.
> It could maybe make all the necessary config.h-like files and set links
> from "config.h" to the right one between build sets (or set an environment,
> etc.). The old methods would still be there for people who need them. Of
> course, this adds entropy...
> Given how much longer the tests have generally taken than the install, I
> typically install everything, then start the tests and go home, off to
> dinner, etc... So, I prefer doing all the tests at the end. But, I'm not
> going to get upset one way or the other. And, I do fall into the "able to
> read a makefile" category.

I second you with this. I think people should be explicit about what they
are testing. If they want to test the serial build, run "make
test.serial", etc. That makes it much easier to ascertain what they did if
they were to go back over their workflow later on (e.g. via analyzing
command history or something). I'd be all for having "make test" just run
"cd test/ && $(MAKE) test.$(INSTALLTYPE)", but I think all of the options
should be available, documented, and maintained. My preferred workflow is:

./configure gnu && make install
./configure -mpi gnu && make install
[./configure -mpi -cuda gnu && make install]
make test.serial
make test.cuda
export DO_PARALLEL=blah && make test.parallel && make test.cuda_parallel
export DO_PARALLEL=blah8 && make test.parallel

And I do this because the Amber build is fast, but the tests are slow, as
Lachele already pointed out.

My 2c,

All the best,

Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
AMBER-Developers mailing list
Received on Tue Feb 14 2012 - 12:00:02 PST
Custom Search