On Mon, Oct 11, 2010, Jason Swails wrote:
>
>
> I'd say it's probably fine to make sander's md.h/memory.h a (soft, hard?)
> link to sqm's since Amber is dependent on tools.
I don't think links are the way to go here. There already is an
$AMBERHOME/AmberTools/src/include directory, which could be home to these files.
On installation of Amber11, this is linked to $AMBERHOME/src/include, so it
works equally well for either sander or sqm. [Note that the links do *not*
need to be present in the git repository; they are created by the configure
script.]
However, the better solution is to not have sqm referring to
sander-specific files like memory.h or md.h at all. This is really a
limitation of the current abstraction: after all, if we want to claim
that sqm is general, and could be linke to other codes (like CHARMM or
pmemd), it cannot depend on files that are really sander files. At some
point, a brave soul needs to figure out which variables are actually
needed by sqm, and get them into an appropriate module that would be
stored in $AMBERHOME/AmberTools/src/sqm, but imported by the code in
$AMBERHOME/src/sander.
[Even if we decide to move sander into AmberTools, we still want sqm to be
independent of details of the sander implementation.]
....dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Oct 11 2010 - 17:30:03 PDT
