On Fri, Jun 29, 2012 at 9:05 AM, David A Case <case.biomaps.rutgers.edu>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_amber.py --patch-level
return something like:
$AMBERHOME/patch_amber.py --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 patch_amber.py
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, patch_amber.py 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 patch_amber.py 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 patch_amber.py
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 patch_amber.py 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 ambermd.org (there's also a section in
the AT manual about it).
All the best,
Jason
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Jun 29 2012 - 07:00:03 PDT
