Thanks to all who commented so quickly. I'll try to give some thoughts
of my own below. Bottom line is that I most like Bob's suggestion, but invite
people to think about whether it might have problems as well as advantages.
On Sat, Jan 30, 2010, David Mathews wrote:
> I would vote for option 1, separate Amber and AmberTools ....
> One way to avoid code duplication is for Amber-* to
> explicitly depend on code in AmberTools-*.
Lots of comments had variants of this idea, which claims to be "option 1" but
is really closer to what I had in mind for "option 2". Here's my argument:
If you make Amber explicitly depend on code in AmberTools, you are closer
to what I called "option 2" than to "option 1". To me the key point is
this: if you don't have code duplication, then you have to ensure that any
update to AmberTools is also compatible with the latest Amber release. My
sense is that we should just live with such a requirement -- we can still
make major changes on the two-year Amber release cycle, but "intermediate"
AmberTools releases cannot break the existing Amber release.
[Said another way: such an "intermediate" AT release could be viewed as a
giant bugfix, but which had too many changes to be conveniently released
just as patch files. Still, logically it would represent changes that do
not break Amber.]
If we agree to enforce this restriction, I am happiest with Bob's
suggestion:
> Have an amberx directory (11, 12, etc.). Under the amberx directory,
> have an AmberTools directory. Encapsulate all of ambertools this way,
> but within the main tree. Seems that might be reasonably organized and
> clear, with everything logically in one package, but divided out so that
> there is not massive confusion about what's ambertools and what's the
> rest of amber...
> As an additional note, you could allow for "overinstall" of a new ambertools
> in the last amber release if it was compatible.
With this option we still have single bin, lib, include directories and
a single config.h file (apart perhaps from pmemd). There is only one
$AMBERHOME variable. But it clarifies what is in AmberTools and what is
not, hence clarifying the license issues at the same time.
[It's a bit tricky to implement Bob's suggestion without considerable updates
to the current CVS repository...there are lots of relative links in Makefiles
that would need to be updated. But this is a solvable issue if we think
it is the best way to go.]
Ben wrote:
> the name AmberTools suggested to me, until I learned better, that
> "Amber" is the key part and "AmberTools" is just some optional extras. I
> long ago realised that the opposite is true, but is it worth thinking
> about an alternative naming scheme that better reflects reality,
Good point, but we need specific suggestions to consider here.
Ross talked about what is in the tar files:
> Trying to explain to people that they have to download AMBERTools
> independently just confuses them. They ask. "So what did I buy?"
I personally handle email for every Amber license, and get a lot of
feedback. I've not had a single complaint about the current requirement
that users download two tar files. And the current procedure emphasizes
the point that Amber and AmberTools are of (roughly) equal importance,
which is the view I hold.
...thanks again for your comments....dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Jan 30 2010 - 21:30:02 PST
