Hi,
On Thu, May 19, 2011 at 07:19:31AM -0400, Daniel Roe wrote:
> Mark, I think you have several valid points here; the install process
> has definitely gotten a lot more complicated. While I agree that
> unifying the code tree again would simplify things, it gets away from
> the original reason that AmberTools was split off from the main tree
> in the first place: to make most of the useful stuff in Amber free to
> the scientific community while still retaining some control over the
But the split could (maybe should) have been irrelevant to
the installation process:
1. there should be only one user 'configure; make; make test' cycle
( whether several independent configures are then called to get
several config.h's or one granddaddy config.h is produced
is an implementation detail that should be hidden ).
2. any release of amber or ambertools should release both and
reset the counter for bugfixes, etc; yes, this means that the
release process must be changed so that the $$ code goes only
to those that paid for it. this can also get us to sensible
version numbers: 12.0 amber+AT, 12.1 amber12 + the next AT.
( and by the way, stop thinking in terms of amber and AT;
there is only Amber: some of it costs $$. )
3. a new release is thus independent of any other release;
amen brother and what were we thinking !!??
4. the one install cycle installs what the user has gotten.
5. this gives us an opportunity to undo this silly amber/AmberTools
directory hierarchy: parts of amber cost money - if u pay
then u get those parts, if u dont pay then u dont get them;
why change the directory hierarchy? changing it was a developer
implementation detail.
On Thu, May 19, 2011 at 07:46:35AM -0400, David A Case wrote:
> On Thu, May 19, 2011, Jason Swails wrote:
> > option would be to sell *only* pmemd, as that program is entirely
> > self-contained (one could argue except for NetCDF libs, but that's unchanged
>
> I think this is a good option, but there are probably lots of ramifications.
> But we should seriously consider it for the next release. We would then make
> an (internal) commitment to keep pmemd self-contained, so that the Amberxx
> and AmberToolsxx are much less intertwined than at present.
This idea looks good. And its easy to work into the above.
Who's in charge of pmemd now ?
scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri May 20 2011 - 12:00:02 PDT
