Re: Suggestion for the GCS

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: Tue, 19 Nov 2002 10:40:41 +0100

> | This is the normal recommended way to invoke configure.
> | We will not desupport that, or even discourage it.
> | It should simply be equivalent to ./configure --build=MACHTYPE.
> 
> I'm fine with keeping it as a synonym of --build, but be aware that
> keeping an interface with a different meaning is probably not as
> sane as completely deprecating the interface.

I don't think the old interface has changed.  We're simply delineating
more precisely what the old interface actually means, and we're
describing a new, upward-compatible option --host=HOSTTYPE that is
already supported by many GNU packages.

How about the following patch instead?  It uses a simpler change in
wording to achieve the effect you desire.  Also, this patch modernizes
the examples, as many current readers won't know what Ultrix or SunOS
4 are, whereas they are much more likely to be familiar with
GNU/Linux.  This patch also adds URLs for config.sub and config.guess,
so that readers know where to get them.

*** standards0.texi     Mon Oct 14 14:58:58 2002
--- standards.texi      Wed Nov 20 15:43:35 2002
***************
*** 3508,3526 ****
  @address@hidden@var{system}
  @end example
  
! For example, a Sun 3 might be @samp{m68k-sun-sunos4.1}.
  
  The @code{configure} script needs to be able to decode all plausible
! alternatives for how to describe a machine.  Thus, @samp{sun3-sunos4.1}
! would be a valid alias.  For many programs, @samp{vax-dec-ultrix} would
! be an alias for @samp{vax-dec-bsd}, simply because the differences
! between Ultrix and @sc{bsd} are rarely noticeable, but a few programs
! might need to distinguish them.
! @c Real 4.4BSD now runs on some Suns.
! 
! There is a shell script called @file{config.sub} that you can use
  as a subroutine to validate system types and canonicalize aliases.
  
  @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
--- 3508,3533 ----
  @address@hidden@var{system}
  @end example
  
! For example, an Athlon-based GNU/Linux system might be
! @samp{i686-pc-linux-gnu}.
  
  The @code{configure} script needs to be able to decode all plausible
! alternatives for how to describe a machine.  Thus,
! @samp{athlon-pc-gnu/linux} would be a valid alias.
! There is a shell script called
! @uref{ftp://ftp.gnu.org/gnu/config/config.sub, @file{config.sub}}
! that you can use
  as a subroutine to validate system types and canonicalize aliases.
  
+ The @code{configure} script should also take the option
+ @address@hidden, which should be equivalent to a
+ plain @var{buildtype} argument.  For example, @samp{configure
+ --build=i686-pc-linux-gnu} is equivalent to @option{configure
+ i686-pc-linux-gnu}.  When the build type is not specified by an option
+ or argument, the @code{configure} script should normally guess it
+ using the shell script
+ @uref{ftp://ftp.gnu.org/gnu/config/config.guess, @file{config.guess}}.
+ 
  @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
***************
*** 3580,3585 ****
--- 3587,3597 ----
  system as both the host and the target, thus producing a program which
  works for the same type of machine that it runs on.
  
+ To compile a program to run on a host type that differs from the build
+ type, use the configure option @address@hidden, where
+ @var{hosttype} uses the same syntax as @var{buildtype}.  The host type
+ normally defaults to the build type.
+ 
  To configure a cross-compiler, cross-assembler, or what have you, you
  should specify a target different from the host, using the configure
  option @address@hidden  The syntax for
***************
*** 3587,3608 ****
  look like this:
  
  @example
! ./configure @var{hosttype} address@hidden
  @end example
  
  Programs for which cross-operation is not meaningful need not accept the
  @samp{--target} 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
- @file{config.guess}), 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.
- 
  Some programs have ways of configuring themselves automatically.  If
  your program is set up to do this, your @code{configure} script can simply
  ignore most of its arguments.
--- 3599,3612 ----
  look like this:
  
  @example
! ./configure address@hidden address@hidden
  @end example
  
+ The target type normally defaults to the host type.
  Programs for which cross-operation is not meaningful need not accept the
  @samp{--target} option, because configuring an entire operating system for
  cross-operation is not a meaningful operation.
  
  Some programs have ways of configuring themselves automatically.  If
  your program is set up to do this, your @code{configure} script can simply
  ignore most of its arguments.