Suggestion for the GCS

[Akim Demaille]

Hi Richard,

We would like to submi the following proposal for a GCS update based
on the experience of the Autoconf and Cross-compiling communitees.
The GCS are slightly ambiguous to someone who does not know anything
about build/host/target, so the following patch tries to make it
clearer.  Also, people have been asking that the chain of defaulting
be

        target ?= host ?= build ?= `config.guess`

this is also what reflects the following patch.  Because of the slight
ambiguity and the possibility of multiple interpretation, but of
conflicts in the dark corners, we also strongly discourage the support
of

        ./configure MACHTYPE

because it's interaction with the options is very unclear.  Actually,
we hare reached a situation where for Autoconf, we would like to drop
completely support for this feature which causes more problems than
good.  So the following patch reflects this idea.  Finally, another
significant difference is that now accepting --target is mandated.  Of
course it makes no sense for some packages, but it is the same as for
the --enable- and --with- familly: in a big tree, you should accept
everybody (but you are free to issue a warning for an inappropriate
--target).

We have been thinking a lot about the following changes.  We do not
believe that changing the GCS is a simple matter, we do not believe
you should blindly accept any suggestion of modification,
nevertheless, the following patch, in its spirit, reflects the four
year old experience of interaction with configure users, ranging from
the novice, up to the cross-compiler writer.

Thanks!


--- standards.texi~     2002-05-29 20:58:40.000000000 +0200
+++ standards.texi      2002-11-18 11:35:26.000000000 +0100
@@ -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 May 29, 2002
address@hidden lastupdate novembre 18, 2002
 @c %**end of header
 
 @ifinfo
@@ -3510,9 +3510,14 @@
 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 must also support the options
address@hidden, which specifies the type of system on which the
+program will be compiled, @option{--host}, which specifies the type of
+system on which the program will be run, and @option{--target}, which
+specifies the type of system which the program will target (e.g., for
+a compiler, this is the system for which it generates executables).
+
+These machine type arguments should look like this:
 
 @example
 @address@hidden@var{system}
@@ -3557,11 +3562,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
@@ -3586,9 +3588,18 @@
 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 the build, 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
address@hidden), so this option is probably not necessary.
+
+Cross-compiling a program (be it a compiler or not) 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 run them,
+defaulting to the build machine type.
 
 To configure a cross-compiler, cross-assembler, or what have you, you
 should specify a target different from the host, using the configure
@@ -3597,21 +3608,10 @@
 look like this:
 
 @example
-./configure @var{hosttype} address@hidden
+./configure address@hidden
 @end example
 
-Programs for which cross-operation is not meaningful need not accept the
address@hidden option, because configuring an entire operating system for
-cross-operation is not a meaningful operation.
-
-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.
+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