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

From: B. Lachele Foley <>
Date: Tue, 14 Feb 2012 18:58:04 +0000

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.

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

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.

:-) Lachele

Dr. B. Lachele Foley
Complex Carbohydrate Research Center
The University of Georgia
Athens, GA USA

From: David A Case []
Sent: Tuesday, February 14, 2012 1:40 PM
Subject: [AMBER-Developers] need suggestions about Amber12 build/test procedure

Hi everyone:

I'm trying to figure out the best behavior to have for the Amber12
install/test procedure.

Right now, the "install" part seems pretty good: the user runs configure,
then "make install" figures out what to install based on what the most
recent configure options were, and what is in the tree (i.e. whether or
not Amber itself is present). The configure script searches for any needed
updates and cleans the source directories in preparation for a new compile.

[Some current problems with PBSA will be going away soon.]

For testing, the same idea could be (but isn't currently) done: "make test"
could figure out kind of tests to run based on options used in the most recent
configure run.

The "problem" (maybe a false one) is that sometimes one would like to run
certain tests without re-running configure. I'm thinking maybe this should
be an "advanced" option: we can have targets like "test.serial",
"test.parallel", etc. available to those who know how to read Makefiles, but
not generally documented or recommended. Most users would run "make test"
right after "make install"; if they want some different tests, they would be
asked to re-configure. This seems safest to me, but I'm hereby soliciting
comments. Is there something better?

Note: for an absolutely complete installation, one would need to do all of the
following (with gnu as example):

   ./configure gnu
   make install
   make test

   ./configure -cuda gnu
   make install
   make test

   ./configure -mpi gnu
   make install
   export DO_PARALLEL=....
   make test

   ./configure -cuda -mpi gnu
   make install
   make test

Is this still too complicated? Will users understand that "make install" and
"make test" only do things called for by the most configure command? Is there
something better?

[To do: Dan and I need to figure out how to install and test things when
the -openmp option is passed to configure.]


AMBER-Developers mailing list

AMBER-Developers mailing list
Received on Tue Feb 14 2012 - 11:00:04 PST
Custom Search