autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bruno Haible
Subject: Re: CC=cc ./configure or ./configure CC=cc
Date: Tue, 8 Aug 2006 16:32:55 +0200
User-agent: KMail/1.9.1

Hello Ralf,

> What does it need to persuade you to move to recommend
>   ./configure CC=cc [...]
> 
> instead of the other way round?  Autoconf (and Automake)
> mailing lists still get bug reports which are due to
>   ./config.status --recheck
> 
> forgetting the settings, which is due to people still
> using (and reading about) the old way of setting CC etc.

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.

2) As a user, when I build packages in several directories in parallel
   in multiple xterms, it's easier to do
     $ echo $CC
   to view the current settings, than to grovel 200 lines across config.status
   in order to see the settings. This is a thing that autoconf could do
   better: show in a comment, very near the beginning of config.status,
   the settings that were used. Not hidden after 200 lines.

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.

4) If "./configure CC=cc" is supported, people may easily think the
   same holds for "make". 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).

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]