Maciej W. Rozycki - Re: Updating top-level autoconf to 2.59 (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

On Fri, 8 Feb 2007, Ian Lance Taylor wrote:

Per autoconf docs, --host is supposed to mean --cross. --native is the absence of --host. No room for inconsistencies in options.

The options are consistent, but, to me, they don't make sense. That is why I completely understand what people mean when they speak of reverse engineering the autoconf options. I know what I want to do, autoconf just doesn't let me specify it in a natural way. There is no obvious reason why I can't specify the host when not building with a cross compiler. From my perspective it's just an odd autoconf rule.

I took part in a discussion about these options a while ago -- when I got rid of autoconf 2.13 and discovered some oddities when trying to treat the top-level configure.in with 2.5x (x being sufficiently low back then for autoconf to be considered in its early atge after the big rewrite). I was surprised with the new convention too, but I got convinced even though I'll have to rewrite some scripts eventually. There are a number of cases to be considered and with the new syntax none is unobvious. They are as follows:

  1. A fully native build:

$ ./configure

  1. A fully native build with a selected build alias:

$ ./configure --build=i386-linux

  1. A native build of a cross-compiler:

$ ./configure --target=alpha-linux

  1. A native build of a cross-compiler with a selected build alias:

$ ./configure --build=i386-linux --target=alpha-linux

  1. A cross-build of a native compiler:

$ ./configure --host=mipsel-linux

  1. A cross-build of a native compiler with a selected build alias:

$ ./configure --build=i386-linux --host=mipsel-linux

  1. A cross-build of a cross-compiler:

$. ./configure --host=mipsel-linux --target=alpha-linux

  1. A cross-build of a cross-compiler with a selected build alias:

$ ./configure --build=i386-linux --host=mipsel-linux --target=alpha-linux

All cases covered, no ambiguity. Now I gather the questionable case is something like:

$ ./configure --build=i386-linux --host=i386-linux

or:

$ ./configure --build=i386-linux --host=i486-linux

One can say that in the first case the host system is compatible with the build system. In the other one it may or it may not be. If the build system is actually i586-pc-linux-gnu, then it is compatible and if it is i386-pc-linux-gnu, then it is not. But how could autoconf guess? I guess it could guess by having a compatibility table, but is it worth the hassle? And confusion? You can repeat this with s/host/target/ and optionally s/build/host above similarly.

The old version of autoconf indeed tried doing guessing whether build == host by trying to run an executable built by the selected compiler, but it is an error-prone approach as there are cases of one-way compatibility systems.

Now one could imagine adding options like --enable-cross-to-host and --enable-cross-to-target, but they would be redundant given the current option semantics and could produce even more surprising results when their complements are applied to configuration selections that are indeed cross-environments.

Having given the reasoning above I gather rather than specifying:

$ ./configure --build=i386-linux

you'd prefer to say something like:

$ ./configure --disable-cross-to-host --host=i386-linux

What's the gain of the latter over the former?

Maciej

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]