On Wed, Aug 29, 2012 at 3:09 PM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
>
> 3) Release an updated cpptraj by itself, outside the normal AmberTools
> release cycle. This has the advantage of all the upgraded
> functionality, but could potentially cause headaches. Cpptraj is
> relatively orthogonal w.r.t. the rest of AmberTools and does have its
> own configure, so the framework is there. However I don't know if this
> is a precedent we want to set.
>
This is my personal favorite. It also wouldn't set the precedent for doing
this: NAB and ptraj were both released externally at one point (NAB via
Dave's website and ptraj via Tom's, IIRC), as was MMPBSA.py in its early
days. It seems this was done when development was too fast for standard
release cycles of AT. (No longer true for any of the above-mentioned
packages).
Cpptraj is, conveniently, standalone, with its own configure (but what
about the routines that require LAPACK?), and very well-versioned. The
only people that need bother with staggered cpptraj releases are those like
the OP that really want otherwise-nonexistent functionality. Quality
control is currently good because you're (Dan) the only one that really
develops on it right now (or at least commits on it).
Like all approaches, it has its drawbacks, but I think is the best of the
available solutions.
4) As a last resort a mega-patch could be used to bring AT12 cpptraj
> up to date with what's in the code, but honestly I don't really like
> that idea. Even with the new patch distribution system the patch
> itself would be enormous, which == lots of places for things to go
> wrong.
>
Ick. It would actually probably handle pretty smoothly (at least according
to my tests with the CUDA patch), but I have plenty of reasons for not
wanting this. The biggest being that we want to provide, as much as
possible, a stable platform where users can implement their ideas and test
them out on our existing code base. If we get into the habit of releasing
these kinds of upgrades, we will force users to re-implement their ideas
each time we decide to release an 'update'. Poor practice, IMO.
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 Wed Aug 29 2012 - 13:00:02 PDT
