I have pushed to the gitosis master some changes that will allow NAB to
be relocatable: you should be able to move the amber tree somewhere, and
re-set your AMBERHOME variable, and keep things working. This required
some changes to a variety of Makefiles:
a. The FLIBS variable (and similar) now use a syntax like "-lnab" rather
than the previous "/home/case/amber11/lib/libnab.a". This means that
Makefiles that use FLIBS have to add a -L$(LIBDIR) before $(FLIBS). I
think I made all the needed changes, but consider this if I have missed
something.
b. AMBERHOME must be set, even during compilation (which is what the
instructions say, but is in fact a change from current practice). One
problem: if AMBERHOME is set, but to the wrong location, strange errors
may get reported. We might want to put more checks in configure to
make sure everything looks ok, and consider removing the option in configure
that allows the user to continue even if AMBERHOME looks wrong. (A
truly clueful super-user who knows what she is doing can just comment
out the checks; ordinary users should probably not be given the opportunity
to plow ahead.]
c. The stand-alone Makefile for cpptraj may be broken by this change. I
looked at fixing it, but it looked broken already anyway, and I figured
Dan would be in the best position to make any changes. I'm kind of
inclined to avoid distributing this, since users are likely to try
something like "cd cpptraj; make install" and have it fail.
d. Note that you still can't move NAB to a machine where there are no
compilers, or where the compilers don't work. gcc (for example) doesn't
need to be the same version as was used during compilation, and it might
be installed in a different location, but gcc has to be in the users' path,
and it still has to work correctly. Also, parallel NAB assumes that
the mpicc in the users' path is the one that should be used; this is often
in $AMBERHOME/bin, so would mess up people who believe that $AMBERHOME/bin
should not be in the PATH variable. I don't see any way around this that
doesn't cause way more complications than it is worth, but others may have
better imaginations.
...dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Nov 18 2011 - 06:30:02 PST
