Looks great... Now just merge the AMBERTools and AMBER src and test
directories, create a nice smart build script that is aware of whether the
tree contains the full AMBER or just the free AMBER + create a script to
allow us to build release tar files for AMBER and FreeAMBER and we are
laughing! :-)
One question. How does the script handle deleting files, creating blank
directories and or brand new files? - I think several versions of patch do
not support patching a non-existant file for example so you need to be
careful here.
All the best
Ross
> -----Original Message-----
> From: Jason Swails [mailto:jason.swails.gmail.com]
> Sent: Monday, November 07, 2011 10:13 PM
> To: AMBER Developers Mailing List
> Subject: [AMBER-Developers] bugfix update script
>
> Hello everyone,
>
> I've put together a prototype script for managing bug fixes for future
> versions of Amber and AmberTools. This should make it much easier for
> the
> user to apply the latest bug fixes without having to jump through the
> hoops
> they used to. I think the benefit this provides is worth the fact that
> it's written in Python :-P (it works on Python 2.4 -- Python 2.7, so it
> should work on every system we've ever tested it on). It's in the
> master
> branch (but if you try to use it there it will just try applying
> Amber11
> and AmberTools 1.5 patches to your git repo -- don't do that :)
>
> To keep this email short, I've attached 3 documents describing how to
> use
> this script, how the script was implemented (which may elucidate
> weaknesses), as well as the format restrictions this places on bug
> fixes
> (basically, just let git do it, but it should not be too different than
> what we have now, except for people not used to making individual
> patches
> that need to be applied from AMBERHOME).
>
> As I think this will do a lot to improve user-friendliness, I would
> *greatly* appreciate any kind of feedback and discussion regarding this
> script. If you can spare it, please take some time, test it out on a
> fresh
> AmberTools 1.5/Amber11 tree, and tell me what you think. How can it be
> improved? Are there any problems with it? Anything unclear? As
> evidenced
> by AT15_Amber11.py (which didn't get much if any testing/suggestions
> before
> it was thrown into production), this will greatly benefit from more
> than
> just my ideas and perspective.
>
> Thanks in advance!
> Jason
>
> P.S. -- A tip from when I was testing this script:
>
> To aid in my own testing, I created a new git repository from the
> AmberTools 1.5/Amber11 checkout with the patch_amber script in it. A
> quick
>
> git init; git add .; git commit -m 'initial commit'
>
> command in that fresh directory (after you copy in patch_amber.py) will
> create the git repository and initialize it. Then, you can always
> restart
> from the beginning with
>
> git clean -f -x -d; git checkout .
>
> from the amber11 directory (that's the only way it'll clean the whole
> directory).
>
> Some things I already know and are not bugs -- Amber bugfixes 9 and 12
> will
> fail unless you use --ignore-fails, since both of those bug fixes try
> to
> fix configure from AmberTools 1.4. The script will only ignore failed
> HUNKs if you force it to (this is intentional). Bugfix.17 for Amber
> will
> complain that no files are there to fix. That's because the patch is
> just
> the header, the actual patch is a hacked-up, bzipped tarball of the
> likes
> that we won't see again (since this new script will be able to allow us
> to
> handle that patch done "correctly").
>
> --
> 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 Mon Nov 07 2011 - 22:30:04 PST
