Updating the GCS on ./configure MACHINE

[Akim Demaille]

(Hi Alexandre!  It's been quite a while :)

I discovered with horror that the GCS are still referring to the old
broken scheme to specify the build/host/target machines :(

Since I know how hard it is to convince RMS, I'd like to make sure
that we agree on the words.  Please, help me making it easier to
accept!  Maybe we should also ask to someone else to submit this
proposal?  I'm thinking about Roland for instance.  I don't know.


This patch is relative to autoconf/doc/standards.texi.

Index: doc/standards.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/standards.texi,v
retrieving revision 1.62
diff -u -u -w -r1.62 standards.texi
--- doc/standards.texi 2 Nov 2001 16:38:16 -0000 1.62
+++ doc/standards.texi 7 Nov 2002 14:20:16 -0000
@@ -3,7 +3,7 @@
 @setfilename standards.info
 @settitle GNU Coding Standards
 @c This date is automagically updated when you save this file:
address@hidden lastupdate October 19, 2001
address@hidden lastupdate November 7, 2002
 @c %**end of header
 
 @ifinfo
@@ -3478,9 +3478,11 @@
 possible, @code{configure} can add to the Makefile a variable named
 @code{srcdir} whose value is precisely the specified directory.
 
-The @code{configure} script should also take an argument which specifies the
-type of system to build the program for.  This argument should look like
-this:
+The @code{configure} script should also support the options (i)
address@hidden, (ii) @option{--host}, and (iii) @option{--target},
+which all take an argument which specifies the type of system where the
+program (i) will be compiled on, (ii) will be run on, (iii) will produce
+binaries for.  These arguments should look like this:
 
 @example
 @address@hidden@var{system}
@@ -3525,11 +3527,8 @@
 @c  Giving an optional @var{parameter} of
 @c @samp{no} should omit @var{package}, if it is used by default.
 
-Possible values of @var{package} include
address@hidden (or @samp{gas}), @samp{gnu-ld}, @samp{gnu-libc},
address@hidden,
address@hidden,
-and
+Possible values of @var{package} include @samp{gnu-as} (or @samp{gas}),
address@hidden, @samp{gnu-libc}, @samp{gdb}, @samp{x}, and
 @samp{x-toolkit}.
 
 Do not use a @samp{--with} option to specify the file name to use to
@@ -3554,9 +3553,12 @@
 cross-compilation.  In such a case, the host and target machines for the
 program may be different.
 
-The @code{configure} script should normally treat the specified type of
-system as both the host and the target, thus producing a program which
-works for the same type of machine that it runs on.
+If @option{--build} only is specified, the @command{configure} script
+should normally treat the specified type of system as both the host and
+the target, thus producing a program which works for the same type of
+machine that it runs on.  The @command{configure} script should normally
+guess the build machine type (using @file{config.guess}), so this option
+is probably not necessary.
 
 To configure a cross-compiler, cross-assembler, or what have you, you
 should specify a target different from the host, using the configure
@@ -3574,12 +3576,11 @@
 
 Bootstrapping a cross-compiler requires compiling it on a machine other
 than the host it will run on.  Compilation packages accept a
-configuration option @address@hidden for specifying the
-configuration on which you will compile them, but the configure script
-should normally guess the build machine type (using
address@hidden), so this option is probably not necessary.  The
-host and target types normally default from the build type, so in
-bootstrapping a cross-compiler you must specify them both explicitly.
+configuration option @address@hidden for specifying the
+configuration on which you will run them, defaulting to the build
+machine type.
+
+The target type normally defaults from the host type.
 
 Some programs have ways of configuring themselves automatically.  If
 your program is set up to do this, your @code{configure} script can simply