Hi,
On Tue, Nov 24, 2009 at 10:19:42PM -0500, case wrote:
> On Tue, Nov 24, 2009, Lachele Foley wrote:
>
> > 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.
There is inconsistent behavior coded in the configure script;
if the serial netcdf configuration fails then amber's configure exits immediately;
if the parallel netcdf configuration fails then amber's configure skips netcdf.
I added an informational comment if the serial fails.
Do we want to change amber's configure to make par and serial netcdf consistent ?
> 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:
>
> env CC=/usr/bin/gcc FC=/usr/bin/gfortran CFLAGS="-O2" (etc) \
> ./configure -static -3drism (etc)
>
> 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.
Let me take this opportunity to not play devil's advocate with Dave :)
and to completely agree that we do not need more features in configure
before 1.3 is released.
My main objection is that more changes will require more testing.
A good principle in software design is to support both a novice and
an expert interface. And we do. The configure expert interface is to
manually edit config.h.
My feeling is that there have already been too many unthoroughly tested
changes in configure. Based on the logs needed changes may have been
undone. I hope to investigate this soon.
Scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Nov 25 2009 - 14:30:04 PST
