[AMBER-Developers] separation of Amber and AmberTools?

From: case <case.biomaps.rutgers.edu>
Date: Sat, 30 Jan 2010 09:22:52 -0500

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.

    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

    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

    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

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.

    Doesn't have the "cons" of Option 1.

    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.


AMBER-Developers mailing list
Received on Sat Jan 30 2010 - 06:30:02 PST
Custom Search