Re: Updating top-level autoconf to 2.59

["Maciej W. Rozycki" <macro at linux-mips dot org>]

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

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

$ ./configure --build=i386-linux


3. A native build of a cross-compiler:

$ ./configure --target=alpha-linux


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

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


5. A cross-build of a native compiler:

$ ./configure --host=mipsel-linux


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

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


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

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


8. 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