> I have an alternate gcc/gfortran installed on a system in /usr/local/bin
> (etc.). If I rearrange my PATH so that the system sees the original
> install (in /usr/bin), AT configures and compiles (testing now). If I
> leave my path so it finds the gcc/gfortran in /usr/local/bin first, the
> configure fails with complaints about gfortran and netcdf.
>
> If there's a way in the configure script to specify alternate library
> paths, I don't see it. I can alter the config.h file, of course, but
> not if the configure script never makes one.

Well, this is a bit of a problem. If the netcdf configuration fails, it
should still make a legal config.h, just with netcdf usage turned off. This
sounds like a bug in the configure script.

The second problem is more problematical: should we allow users to point
to their preferred compilers by some means other than adjusting their PATH
variable? I'm inclined to think not: users that know enough to have multiple
compilers installed in their systems can surely temporarily adjust their PATH
variable when configuring and compiling Amber, returning it to its original
state later if desired.

We certainly could (as Volodymyr will not doubt suggest) pick up environment
variables so that Lachele could enter something like this:

My (mildish) objection is that we have to make sure this all works OK, we
have to document it, and (the real problem): we have to try to remotely
debug all kinds of weird behavior people will report because they actually
have a "CC" environment variable without knowing it.

My general feeling is that it is better to make an experienced user like
Lachele temporarily edit her PATH, than to make things harder than they
already are for novice users.