Re: [AMBER-Developers] Having to run configure multiple times

From: Jason Swails <>
Date: Fri, 29 Jun 2012 09:52:52 -0400

On Fri, Jun 29, 2012 at 9:05 AM, David A Case <>wrote:

> On Thu, Jun 28, 2012, Jason Swails wrote:
> >
> > 1) We could change the AmberTools 12 release tarball to include this new
> > configure script so that when new users download AT12, it will
> > automagically work. Existing users, in all likelihood, have already
> > applied bugfix.3 (since they configured at least once already), so this
> > issue doesn't apply to them anymore.
> I'm inclined to do the above. I've prepared the modified tarball (with
> configure from the current master branch). Tests indicate that it is
> working
> as expected. The key advantage I see for this is that users that just
> download and install AmberTools12 once stand a better chance of getting all
> the patches applied.
> People that think this is a bad idea, or who have a better idea (and maybe
> we
> haven't thought of everything) should speak up now.

The only reason I'm not the biggest fan is that configure has now diverged,
which makes it harder to patch. This is probably not a big deal, though,
since it's just a wrapper and is unlikely to change.

Another idea is to package up and release a AmberTools 12.11 which has all
11 patches applied and logged so that users that download and extract it
will have

./ --patch-level

return something like:

$AMBERHOME/ --patch-level
Latest patch applied to AmberTools12: 11

This has the side-benefit of no divergence between different AT downloads
(i.e., everyone has the same thing still, whether by using
the whole time or downloading the new tarball). Also, if people download
the 'updated' version and extract it into a dirty tree, it'll still work
fine. (and since bugfix.3 is applied, will never 'stop'
without applying all fixes)

Creating the tarball shouldn't be much more difficult, either. Just
extract a fresh AT12.tar.bz2, run twice, and then tar
everything back up (including the files in .patches/, which is how fixes
are logged). We can also release a bugfix.12 that updates the configure
script to the git version, as well, so we are free to patch
should the need arise. (I will generate this tarball if desired).

The downside is that this diverges more from what we've done in the
past... Not sure what is better.

Another upside is that we can incorporate some of the Manual errata into
the PDF, but this may also cause more headaches with Lulu (?).

Note that we also have to encourage users to re-run from time
> to time in order to update their codes.

Not sure the best way to implement this... I'll add notes to the
installation pages on my Wiki and (there's also a section in
the AT manual about it).

All the best,

Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
AMBER-Developers mailing list
Received on Fri Jun 29 2012 - 07:00:03 PDT
Custom Search