Hi Michael,
On 7/11/2011, at 6:01 p.m., Michael Sternberg wrote:
> I am new to Amber and am struck by the rather non-canonical install procedure.
If it's any comfort to you, you aren't the first to be bewildered by Amber's installation procedure. I believe the reasons why it's this way are chiefly historical - Amber is a complicated package that arose before install procedures from source became standardised.
> Is there a way to coax Amber into this pattern or am I bumping against the old-school assumptions? For one thing, the auxiliary python gets hardwired with the source tree location.
As far as I know, if you want multiple different builds of Amber to coexist on the same system, you'll need corresponding copies of the source tree. Alternatively, you could perhaps achieve the same goal by renaming your binaries (in $AMBERHOME/bin), running "make clean" and rebuilding with a different set of options; but I can't say for sure that that approach will work, and it certainly seems like a lot of trouble to go to.
> There's also catch-22 in that AmberTools wants to be unpacked into the same location as Amber, and built first, but it still requires $AMBERHOME.
The general assumption is that you set $AMBERHOME in your working shell before you start building AmberTools; see e.g. section 1.2 in the AmberTools manual.
Hope that helps,
Ben
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Nov 07 2011 - 15:30:03 PST
