Hello, Peter!
> I don't think this buys anything. First let me say that this "target"
> thing is about the most confusing thing about Autoconf documentation and
> concept-wise, especially when thrown together with build and host. The
> latter two configure the build process to some extend or other. Target is
> really just another option to configure the runtime behaviour of the
> package to be built.
It's great that you pointed this out! I agree that AC_CANONICAL_TARGET is
out of scope of Autoconf, especially the way how TARGET is canonicalized.
BUILD describes one machine that builds the program.
HOST describes a class of similar machines that are more or less
compatible with each other on the binary level. Sometimes they also should
have some common software installed, i.e. if the binary depends on libfoo,
libfoo must be installed.
TARGET is limited only by capabilites of the program that you are
compiling. You can have many targets. You can define them how you
want. Sometimes you need to be specific and define target exactly,
e.g. sparc-sun-solaris2.6. Sometimes only architecture is relevant.
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.
Regards,
Pavel Roskin
