Date: Fri, 21 Apr 2000 19:03:50 -0400 (EDT)
From: Pavel Roskin <[EMAIL PROTECTED]>
In fact GNU software has already outgrown the concept of a single TARGET.
GDB and Binutils support multiple targets. Even gcc supports many targets,
i.e. gcc and "gcc -mlittle-endian" on PowerPC generate absolutely
different code.
In this case we have only two situations we should care about - configure
that is aware of BUILD and HOST and configure that is not aware of them.
I'm not sure whether AC_CANONICAL_TARGET should be dropped. An important
word here is "canonical". Autoconf used to provide some service to the
package, namely canonicalization of exactly one option that Autoconf
itself doesn't use. Some software may depend on it, although, as I said
before, the GNU toolchain has outgrown this approach.
The GNU toolchain hasn't outgrown --target, because the current
situation existed from the start. The GNU binutils always supported
multiple targets. However, they default to a particular target, and
that is what they use the --target option for. Additional targets are
specified using --enable-target. (--enable-target is actually a newer
innovation. Previously, the GNU binutils always supported all targets
(i.e., what is now --enable-targets=all). Adding --enable-target was
part of trimming down the binutils, speeding up the build and
shrinking the sizes of the binaries).
In any case, I think tradition requires that we keep the --target
option, and that means that autoconf must continue to support it.
Canonicalizing that target remains an important function. I don't see
anything wrong with keeping AC_CANONICAL_TARGET.
By the way, people talk about AC_CANONICAL_TARGET and
AC_CANONICAL_BUILD, but in earlier years those were never documented.
The only documented macros were AC_CANONICAL_HOST (only used by
programs which cared about the host) and AC_CANONICAL_SYSTEM (only
used by programs which support Canadian Cross, or which had a
distinction between host and target).
Ian
