AMBER Archive (2008)

Subject: Re: AMBER: AMBER10 AMBERTools antechamber

From: M. L. Dodson (activesitedynamics_at_comcast.net)
Date: Tue Dec 23 2008 - 14:00:13 CST

David A. Case wrote:
> On Tue, Dec 23, 2008, Ross Walker wrote:
>> Indeed, you can't do this with AMBERtools and it annoys the hell out of me,
>> especially if you are trying to do development where you have a single cvs
>> tree for example and multiple links to different locations. For the time
>> being all you can do is keep it in the path you compiled it in.
>>
>> For AMBER developers: I propose that we remove this restriction for the next
>> version of AMBER tools and have it use the AMBERHOME environment variable
>> like previous versions of AMBER always did.
>
> Counter arguments go like this:
>
> (1) Relying on correct settings for environment variables creates its own
> opportunities for failure;
>
> (2) it's better to inconvenience smart developers like Ross than to
> inconvenience new users who may not even understand what environment variables
> are, and won't know how to diagnose error messages;
>
> (3) it doesn't take long to build AmberTools from source, so the developer
> inconvenience is minimal (!?!);
>
> (4) if you build from source, then you know that the compilers used are there
> and compatible with what you built. This is especially true for nab, which
> relies entirely on the underlying compiler. If you copy the nab binary to
> some other platform, (with different compilers) it's likely to fail in odd
> ways. Other compilers (like gcc) often hardwire in their search
> paths, probably for just this reason. With Ross' suggestion, different
> users with different PATH variables would find nab failing in
> hard-to-diagnose ways if the compiler or libraries were changed, even if
> the nab binary were found.
>
> (5) You can't just move binaries, since programs need to know the
> locations of things in $AMBERHOME/dat, etc. Knowing what to move and
> how is for experienced people -- see point (2) above. Also, in the
> past, we ended up with multiple environment variables, ACHOME,
> AMBERHOME, NABHOME, etc.
>
> Commentary and objections are welcome.
>
> ...regards...dave

Well, I'll just jump in here to voice my thoughts (are we up to 4
cents yet? ;-)

Doing it the way it is done now locks you in to the "run from where
you build paradigm". I hate to appeal to authority (especially when
replying to an authority), but when I describe this to software design
people (I have experience with the FreeBSD folk), they universally
condemn this characteristic of AMBER s/w. I know it seems like a
burden to have to insist beginners set an environment variable, but we
already have to set AMBERHOME. Without having done it and being ready
to send you patches, it seems not a very difficult proposition to be
able to locate all the various directories relative to AMBERHOME.
(Some call this "standards".) I don't think anyone would argue that we
should be able to willy-nilly reorder the whole directory tree, only
move the root (which can always be located with AMBERHOME).

Bud Dodson 

-- 
M. L. Dodson
Business Email: activesitedynamics-at-comcast-dot-net
Personal Email:	mldodson-at-comcast-dot-net
Phone:	eight_three_two-56_three-386_one
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber_at_scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
      to majordomo_at_scripps.edu