I agree with Bob here with one modification.
I do not think we should split the trees. I think we can accomplish this by
using mkrelease scripts for AMBER and AMBERTools. Make AMBER a true superset
that includes ALL of AMBERTools in addition to other value add items. This
way we don't end up with forking, issues with compatibility, two sets of
code bases to maintain etc. The key is that Makefile should be EVERYTHING
while Makefile_at should be just AMBERTools. NOT the current situation of
Makefile_at = AMBERTools and Makefile is sander / pmemd but missing all
sorts of stuff that would make it complete and standalone. Such as netcdf
etc.
All the best
Ross
> -----Original Message-----
> From: amber-developers-bounces.ambermd.org [mailto:amber-developers-
> bounces.ambermd.org] On Behalf Of Robert Duke
> Sent: Saturday, January 30, 2010 8:32 AM
> To: AMBER Developers Mailing List
> Subject: Re: [AMBER-Developers] separation of Amber and AmberTools?
>
> I would split the trees also; I would make amber dependent on
> ambertools,
> with the ambertools location defined by an environment variable - say
> AMBERTOOLS_HOME, or something else everyone is comfortable with, while
> AMBERHOME remains the root of the amber product. This gets rid of the
> duplication issues, allows development work in the separate trees, and
> gets
> rid of the lack of clarity as to what is what, how you build,
> sequencing,
> etc. The fewer overlapping efforts per directory, the better, as a
> general
> rule...
> Regards - Bob
> ----- Original Message -----
> From: "David Mathews" <David_Mathews.urmc.rochester.edu>
> To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
> Sent: Saturday, January 30, 2010 11:12 AM
> Subject: Re: [AMBER-Developers] separation of Amber and AmberTools?
>
>
> > Hi All,
> >
> > I have one quick thought about this and it relates to
> something I
> > do with RNAstructure development.
> >
> > I would vote for option 1, separate Amber and AmberTools
> > repositories, which Dave gave the con of:
> > "Considerable code duplication: sqm, pbsa, rism, lib (others?) would
> > be present in both releases."
> >
> > One way to avoid code duplication is for Amber-* to
> explicitly
> > depend on code in AmberTools-*. This makes sense because AmberTools
> is
> > freely available, so it is unlikely that one would have Amber without
> > AmberTools.
> >
> > This would depend on users and developers having the code
> trees
> > adjacent in their directory structure, so the dependencies can be
> > resolved. It would also mean that developers would need to do a cvs
> > update in both sandboxes to keep things synchronized. There would
> also be
> > some details to work out in specifying exact dependencies if the two
> > repositories had version numbers in the directory names. In my
> opinion,
> > this is much better than allowing code duplication, which will
> certainly
> > be very confusing.
> >
> > Another possible option 3 is switching to SVN, which I
> understand
> > is much better at handling changes to directories. One could then
> have a
> > single repository in SVN that would have Amber and AmberTools
> > side-by-side. As versions of each change, new directory names would
> be
> > placed in the SVN repository.
> >
> > Sincerely,
> > Dave
> >
> >
> >
> >
> > At 09:22 AM 1/30/2010, you wrote:
> >>At the developers' meeting, there were various suggestions for how to
> >>handle the Amber/AmberTools split. This is a request for comments
> for
> >>some
> >>ideas along this line.
> >>
> >>Option 1:
> >> unpack Amber into a tree headed at Amber-11.0/
> >> unpack AmberTools into a tree headed at AmberTools-2.0/
> >>
> >> Each would be a full and separate package. Users would set
> AMBERHOME
> >> to the AmberTools-2.0 location, since Amber codes don't use such
> a
> >> variable. Users would put both Amber-11.0/bin and AmberTools-
> 2.0/bin
> >> in their PATH.
> >>
> >> Amber users would still need AmberTools, as in a package
> dependency.
> >>
> >>Pros:
> >> Simple to explain to users. We could upgrade AmberTools without
> >> worrying about Amber. Amber tests and AmberTools tests would be
> >> cleanly separated.
> >>
> >> Having versioned directory names is more in line with gnu/linux
> >> software
> >> practices.
> >>
> >> We could support different compilers/OS's in AmberTools than in
> >> Amber;
> >> the configure script and config.h file would not be required to
> be
> >> the
> >> same. For example, we would probably not need to support pgcc
> for
> >> AmberTools.
> >>
> >>Cons:
> >> Considerable code duplication: sqm, pbsa, rism, lib (others?)
> would
> >> be present in both releases. Bug fixes would have to be made in
> two
> >> places, using different patch files as the two codes diverge.
> If we
> >> indeed have AmberTools releases not coordinated with Amber
> releases,
> >> then we have the awkward situation that the functionality and
> results
> >> for the same calculation (e.g. QM) are different in the two
> codes.
> >> If we truly separate the two parts, we would need massive
> >> documentation
> >> duplication as well as code duplication.
> >>
> >> Hard for developers, since the tree that users would see is
> different
> >> from the one we are developing on. (This is probably a minor
> >> concern.)
> >>
> >> Psychologically, we weaken the perception that AmberTools is a
> >> "genuine
> >> part of Amber". (This might be a rather important drawback; or
> maybe
> >> not.)
> >>
> >>Option 2:
> >> Continue with the current model: both codes unpack into an
> amber11
> >> tree, which AMBERHOME points to. We make sure that any updates
> to
> >> AmberTools (either through bugfixes or an intermediate release)
> >> remain
> >> compatible with Amber -- no more "jumping ahead" to a new
> directory
> >> tree as we did with AmberTools-1.3.
> >>
> >>Pros:
> >> Doesn't have the "cons" of Option 1.
> >>
> >>Cons:
> >> Doesn't have the "pros" of option 1. Might be quite difficult
> to
> >> meet
> >> the requirement that changes in AmberTools have to "work" inside
> the
> >> same
> >> tree as Amber itself. Hard to keep licensing terms clear when
> code
> >> with
> >> very different licenses reside inside the same tree.
> >>
> >>Option 3:
> >> Something different from the two listed above.
> >>
> >>Comments? I'd like to get this figured out soon, since attempts to
> clean
> >>up the installation (e.g. merge src/Makefile with src/Makefile_at)
> depend
> >>on what we decide.
> >>
> >>Please think hard about the branding and perception issues -- the
> other
> >>things
> >>are mostly technical that we can probably solve.
> >>
> >>....thx....dac
> >>
> >>_______________________________________________
> >>AMBER-Developers mailing list
> >>AMBER-Developers.ambermd.org
> >>http://lists.ambermd.org/mailman/listinfo/amber-developers
> >
> > ___________________________________________________
> > David Mathews, MD, PhD
> > Assistant Professor of Biochemistry & Biophysics
> > and of Biostatistics & Computational Biology
> > University of Rochester Medical Center
> > Room 3-6830
> > 601 Elmwood Avenue, Box 712
> > Rochester, New York 14642
> > http://rna.urmc.rochester.edu
> >
> >
> >
> >
> > _______________________________________________
> > AMBER-Developers mailing list
> > AMBER-Developers.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber-developers
> >
> >
>
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Jan 30 2010 - 14:30:03 PST
