Re: CC=cc ./configure or ./configure CC=cc

[Ralf Wildenhues]

Hello Bruno,

* Bruno Haible wrote on Tue, Aug 08, 2006 at 04:32:55PM CEST:
> 
> > What does it need to persuade you to move to recommend
> >   ./configure CC=cc [...]
> > 
> > instead of the other way round?
> > mailing lists still get bug reports which are due to

> Hmm, there are four reasons why I still recommend to use configure
> with environment variables:
> 
> 1) For the user, especially when building several packages, or needing
>    several attempts until one succeeds, it's simpler to set an environment
>    variable once for the entire session, than to remember to set not
>    only --prefix, but all the other stuff, at every configure invocation.

This strikes me as inconsistent, although I see your point.
Personally, I tend to just put the whole configure line in a (one-line)
script or a shell variable.  Or use shell history.  The fact that you
have to remember --prefix and some other options anyway is a good reason
to treat all of them in the same way.

> 2)

was addressed by Andreas already.  I could note that I proposed a
  ./config.status --config

with output reusable for another configure invocation, a while
(about a year, IIRC) ago, but we couldn't easily make it work well
with all kinds of corner cases, and I forgot about it afterwards.

> 3) A recommendation to use VAR=value in the configure command line will
>    not work with some 'configure' scripts that comply to GNU standards
>    but are not generated by autoconf. For example, GNU clisp's toplevel
>    configure script is written by hand and does not support VAR=value.
>    In other words, if you want to make universal recommendations, they
>    should IMO be based on the GNU standards.

OK, if that's what it takes to convince you, that is what we should do
(quickly).

> 4) If "./configure CC=cc" is supported, people may easily think the
>    same holds for "make".

I don't think that is such a problem in practice.

> Such as "make CC=cc" or
>    "make install prefix=/opt/gnu". But these are unsupported (the
>    first one because so many details about $CC are extracted into
>    config.h, the second one because paths to message catalogs etc.
>    are hardcoded into the built executables).

Both are used widely though, the first to do minor changes, like a quick
debugging build with -g added to $CC or $CFLAGS (yes, we all know that
this could in principle also alter config.h values, but we are
reasonable and prepared to expect that case ;-), and the second is
mentioned in the GCS (section 'Directory Variables') as another way to
do staged installs, although I like DESTDIR much better and think the
other should be banished for the reasons you state.

Cheers,
Ralf