On Tue, 2009-11-24 at 23:00 -0500, Volodymyr Babin wrote:
> > 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.
>
> 1. My suggestion is not really my -- this is something used for
> years by gnu autotools (autoconf/automake/etc). One could try to
> copy just this part (passing CC/FC/etc through environment) while
> still going with the hand-written configure/makefiles. Every platform
> would have its .h file that sets CC/FC/etc; this way configure
> would be (partially) decoupled from the platform-specific stuff.
> I don't know whether it good or bad, but (for my project) I would
> prefer it over one big and smart (hand written) configure.
>
> 2. What if every package had its own configure? Like, for example,
> many gnu projects have (xorg/kde/gnome)? I tend to think that for
> C/C++ projects this would be better from every perspective.
> It probably does not make much sense to change the current framework
> significantly, but definitely something to keep in mind for the
> future projects.
OK, here's my $0.02 worth...
Another option (again, not necessarily for the present release) would be
to have the compiler (optionally) specified via command-line flags to
the configure script. Thus, for example,
./configure gnu
would set CC to "gcc", CPLUSPLUS to "g++", and FC to "gfortran", while
./configure gnu --cc="/usr/local/bin/gcc"
would have a corresponding effect. Under this model, the "gnu" would
still be needed, I suppose, to set the appropriate compiler flags.
I at least would find that approach safer for the controlling shell (and
the slightly forgetful user's sanity) than modifying the PATH. Whether
it's better than using the CC, FC, etc. variables is another question.
If after consideration we decide to go with the environment variable
approach, one thing that could be done in the "configure" is throw up an
"are you sure" prompt for each compiler that has been specified via an
environment variable. But I'm not going to definitely advocate for that
approach yet; it seems to me that it would annoy certain users who know
what they're doing, and we might still get the odd curly question from
novices who fail to read (or don't fully understand) the question but
answer "yes" anyway. No doubt Dave and others know better than me
whether that risk is small or large.
Ben
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Nov 24 2009 - 21:00:02 PST
