bug-gnulib
[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: Ralf Wildenhues
Subject: Re: CC=cc ./configure or ./configure CC=cc
Date: Wed, 9 Aug 2006 22:26:57 +0200
User-agent: Mutt/1.5.12-2006-07-14

Hello Bruno,

Let's move the GCS-related part of this discussion to bug-gnulib.

* Bruno Haible wrote on Tue, Aug 08, 2006 at 04:32:55PM CEST:
> 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.

FWIW, GNU clisp's toplevel configure script fails to comply with current
GCS in several ways.  For example, it does not write a config.status
file and there is no provision for a rerun mechanism.  The first
non-option argument is treated as directory name, but my reading of the
GCS is that it is required to be taken as $host setting.  Which, BTW,
seems to me a rather unfortunate requirement: Autoconf has deprecated
this usage several years already.

>    In other words, if you want to make universal recommendations, they
>    should IMO be based on the GNU standards.

Well, here's a stab at the GCS to improve it.  I noticed several issues
(sorry for the long mail):


1) First, the order of subsections output in GCS is inconsistent between
the DVI and the info output (this does not happen with sections as in
the GNU make manual, but only with the section-lowering as done for the
GCS; makeinfo bug lingering here?).

2) While at it, fix the text reference to say section/subsection/node
correctly (for both GCS and the GNU make manual).

3) There is a content error in the DESTDIR node: it does not work to
specify DESTDIR at configure time, because that will not be stored in
the Makefile.  There is a good reason for this (and the fact that it
won't be stored is even mentioned in make-stds itself): this way, make
macro override works portably from the command line at install time.

(1)-(3) Should be fixed by this patch:

        * make-stds.texi (menu): Adjust to changed node order.
        (Command Variables): Adjust speaking of node/section/subsection
        depending on the output format.
        (DESTDIR): This variable is not specified to the configure
        script.

Index: doc/make-stds.texi
===================================================================
RCS file: /cvsroot/gnulib/gnulib/doc/make-stds.texi,v
retrieving revision 1.11
diff -u -r1.11 make-stds.texi
--- doc/make-stds.texi  10 Jul 2006 13:16:09 -0000      1.11
+++ doc/make-stds.texi  9 Aug 2006 20:01:49 -0000
@@ -39,8 +39,8 @@
 * 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.
+* 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.
@@ -273,7 +273,18 @@
 @end example
 
 However, it is preferable to support a @code{DESTDIR} prefix on the
-target files, as explained in the next section.
+target files, as explained in the next
address@hidden
+node.
address@hidden ifinfo
address@hidden
address@hidden CODESTD
+subsection.
address@hidden ifset
address@hidden CODESTD
+section.
address@hidden ifclear
address@hidden iftex
 
 @noindent
 Always use a file name, not a directory name, as the second argument of
@@ -296,9 +307,8 @@
 $(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a
 @end example
 
-The @code{DESTDIR} variable is specified by the user, either to the
address@hidden script or, more commonly, on the @code{make} command
-line.  For example:
+The @code{DESTDIR} variable is specified by the user on the @code{make}
+command line.  For example:
 
 @example
 make DESTDIR=/tmp/stage install

 

4) OK to apply this trivial dependency omission to gnulib?

        * Makefile (standards.info standards.html standards.dvi):
        Also depend on make-stds.texi.

Index: doc/Makefile
===================================================================
RCS file: /cvsroot/gnulib/gnulib/doc/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- doc/Makefile        19 Jun 2006 20:40:26 -0000      1.3
+++ doc/Makefile        9 Aug 2006 20:22:44 -0000
@@ -16,3 +16,5 @@
 info: $(doc).info
 html: $(doc).html
 dvi: $(doc).dvi
+
+standards.info standards.html standards.dvi: standards.texi make-stds.texi


5) Finally, to address the 'CC=cc configure' vs 'configure CC=cc'
(which, interestingly, has been alluded to already in the part which was
removed above in the process of fixing (3)), here's a proposed patch to
the GCS.  Thoughts?  Does this need to go by RMS, and if yes, is there
somebody to do this for me, after this has been improved to a phrasing
that finds consensus?

Cheers,
Ralf

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

Index: doc/standards.texi
===================================================================
RCS file: /cvsroot/gnulib/gnulib/doc/standards.texi,v
retrieving revision 1.18
diff -u -r1.18 standards.texi
--- doc/standards.texi  10 Jul 2006 13:16:09 -0000      1.18
+++ doc/standards.texi  9 Aug 2006 20:58:36 -0000
@@ -3761,8 +3761,9 @@
 
 @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:
+or hardware present on the machine, adjust the name of some tools
+or arguments to them, and include or exclude optional parts of the
+package:
 
 @table @samp
 @item address@hidden@address@hidden@r{]}
@@ -3795,14 +3796,30 @@
 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.
+
address@hidden @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} to build with debugging symbols.
+Specifying variables as arguments to @code{configure}:
address@hidden
+./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
address@hidden
 @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.
+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
address@hidden  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




reply via email to

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