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

[Ralf Wildenhues]

Hello Karl,

Sorry for the delay.

* Karl Berry wrote on Fri, Aug 11, 2006 at 12:51:10AM CEST:
> 
>     3) There is a content error in the DESTDIR node: it does not work to
>     specify DESTDIR at configure time, 
> 
> Ok, good.

>     +./configure CC=gcc
>     address@hidden example
>     +is preferable over setting them in environment variables:
>     address@hidden
>     +CC=gcc ./configure
>     address@hidden example
>     +as it helps to recreate the same configuration later with

> Actually, I've never understood this move in Autoconf.  Everyone
> understands setting environment variables.  Why was it necessary to
> recommend (nearly require) making the settings via options instead?
> Can't you just take the relevant environment settings and do exactly the
> same thing in config.status (and wherever else) as if it had been an
> option?  Can you explain?

Of course.  The problem lies in the recheck operation of config.status:
it reruns configure, with the intent to recreate the same configuration
as the original one.  For (other configure options and) variables
specified on the command line, it just specifies them again on the
command line.  For config.status to remember changes to arbitrary
environment variables, it would have to actually _know_ the exact set of
environment variables to store and recreate.  This is the heart of the
matter: it's not practical nor desirable to restore the _complete_
environment (think stuff like session IDs stored in variables), but in
reality, it's neither practical to know beforehand which set of
variables the user would like to be restored: CC and CFLAGS are pretty
obvious, but what about some variable some obscure compiler needs to be
set in a certain way?

So, important variables like CC and CFLAGS are already stored even when
specified as environment variables (i.e., they are "precious variables":
http://www.gnu.org/software/autoconf/manual/html_node/Setting-Output-Variables.html
has more details).  But specifying variables on the command line helps
to eliminate this ambiguity neatly for any variable, including those
that neither the authors of Autoconf nor those of the package in
question knew about (or thought of as important to retain).

BTW, I forgot one point addressing Bruno's objections: if you want
hundreds of identical configurations, a config.site file would come
handy as an easy way to change settings more globally.

> Anyway, regardless, I'm sure you-all have a good reason for the move,
> so, can you make a single revised patch, with Bruno's additional fixes,
> for me to convey?

Here you go.

Cheers,
Ralf

2006-08-14  Ralf Wildenhues  <address@hidden>
        and Bruno Haible  <address@hidden>

        * make-stds.texi (menu): Adjust to changed node order.
        (DESTDIR): This variable is not specified to the configure
        script.

        * standards.texi (Configuration): Document that `configure'
        should accept arguments of the form `VARIABLE=VALUE' and why
        they are preferable over environment variables.

*** make-stds.texi      2006-08-11 18:35:23.000000000 +0200
--- make-stds.texi      2006-08-11 18:25:20.000000000 +0200
***************
*** 39,46 ****
  * Makefile Basics::             General conventions for Makefiles.
  * Utilities in Makefiles::      Utilities to be used in Makefiles.
  * Command Variables::           Variables for specifying commands.
- * Directory Variables::         Variables for installation directories.
  * DESTDIR::                     Supporting staged installs.
  * Standard Targets::            Standard targets for users.
  * Install Command Categories::  Three categories of commands in the `install'
                                    rule: normal, pre-install and post-install.
--- 39,46 ----
  * Makefile Basics::             General conventions for Makefiles.
  * Utilities in Makefiles::      Utilities to be used in Makefiles.
  * Command Variables::           Variables for specifying commands.
  * DESTDIR::                     Supporting staged installs.
+ * Directory Variables::         Variables for installation directories.
  * Standard Targets::            Standard targets for users.
  * Install Command Categories::  Three categories of commands in the `install'
                                    rule: normal, pre-install and post-install.
***************
*** 296,304 ****
  $(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a
  @end example
  
! The @code{DESTDIR} variable is specified by the user, either to the
! @file{configure} script or, more commonly, on the @code{make} command
! line.  For example:
  
  @example
  make DESTDIR=/tmp/stage install
--- 296,303 ----
  $(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a
  @end example
  
! The @code{DESTDIR} variable is specified by the user on the @code{make}
! command line.  For example:
  
  @example
  make DESTDIR=/tmp/stage install
*** standards.texi      2006-08-11 18:35:23.000000000 +0200
--- standards.texi      2006-08-11 18:25:32.000000000 +0200
***************
*** 3761,3768 ****
  
  @cindex optional features, configure-time
  Other options are permitted to specify in more detail the software
! or hardware present on the machine, and include or exclude optional
! parts of the package:
  
  @table @samp
  @item address@hidden@address@hidden@r{]}
--- 3761,3768 ----
  
  @cindex optional features, configure-time
  Other options are permitted to specify in more detail the software
! or hardware present on the machine, to include or exclude optional parts
! of the package, or to adjust the name of some tools or arguments to them:
  
  @table @samp
  @item address@hidden@address@hidden@r{]}
***************
*** 3795,3808 ****
  Do not use a @samp{--with} option to specify the file name to use to
  find certain files.  That is outside the scope of what @samp{--with}
  options are for.
  @end table
  
! All @code{configure} scripts should accept all of these ``detail''
! options, whether or not they make any difference to the particular
! package at hand.  In particular, they should accept any option that
! starts with @samp{--with-} or @samp{--enable-}.  This is so users will
! be able to configure an entire GNU source tree at once with a single set
! of options.
  
  You will note that the categories @samp{--with-} and @samp{--enable-}
  are narrow: they @strong{do not} provide a place for any sort of option
--- 3795,3826 ----
  Do not use a @samp{--with} option to specify the file name to use to
  find certain files.  That is outside the scope of what @samp{--with}
  options are for.
+ 
+ @item @address@hidden
+ Set the value of the variable @var{variable} to @var{value}.  This may
+ be used to override some commands or arguments to values differing from
+ the ones the build process would use otherwise.  For example, the user
+ could issue @samp{configure CFLAGS=-g CXXFLAGS=-g} to build with
+ debugging information and without the default optimization.
+ 
+ Specifying variables as arguments to @code{configure}:
+ @example
+ ./configure CC=gcc
+ @end example
+ is preferable over setting them in environment variables:
+ @example
+ CC=gcc ./configure
+ @end example
+ as it helps to recreate the same configuration later with
+ @file{config.status}.
  @end table
  
! All @code{configure} scripts should accept all of the ``detail''
! options and the variable settings, whether or not they make any
! difference to the particular package at hand.  In particular, they
! should accept any option that starts with @samp{--with-} or
! @samp{--enable-}.  This is so users will be able to configure an entire
! GNU source tree at once with a single set of options.
  
  You will note that the categories @samp{--with-} and @samp{--enable-}
  are narrow: they @strong{do not} provide a place for any sort of option