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
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
to majordomo.scripps.edu
Received on Wed Dec 24 2008 - 01:21:47 PST
