Re: Updating top-level autoconf to 2.59

[Alexandre Oliva <aoliva at redhat dot com>]

On Feb  9, 2007, Ian Lance Taylor <iant@google.com> wrote:

> I just routinely
> specify all of --build, --host, and --target.  With autoconf's rules,
> I have to do an odd little dance to remove --host and/or --target in
> some cases.  That dance is completely doable but it is not, I believe,
> intuitive.

With the alternate rules proposed upthread, you'd have just a
different kind of odd little dance to specify the options to enable
cross compilation.  Which would be just as bad, possibly even worse.

The current scheme removes a lot of the ambiguity from earlier
guessing with, I believe, the least hassle, even though it creates
some inconvenience during the transition, until you get used to the
new conventions.

In the end, the only way to avoid the guessing that led to incorrect
results in the past is to get the user to supply the needed
information, and the current rules accomplish that without inventing
new options that would make room for inconsistencies, while still
working seamlessly most of the time.

And in case one is really unhappy about the implied cross-compilation
with host=build or cross-toolchain status when target=host, it's not
too hard to work around that on a per-project basis.  But then, does
it really matter?

> If we add options to say "build with native compiler/cross-compiler"
> and "build a native toolchain/cross-compiler" then it becomes much
> simpler to reason about what you want to happen.

I *think* this is just because you're looking at it from the
perspective of someone already used to what was in place before.  If
you start with a clean slate, it becomes a problem of "what should I
specify to accomplish what I want?".  Do I want to name the platform
I'm building on (--build), or let autoconf guess it?  Do I want to
build programs to run on a different platform (--host) or not?  Do I
want to build a cross toolchain (--target) or not?  Can it possibly
get simpler than this?

> And note that adding such options is completely backward compatible.
> They would just override the way that autoconf makes assumptions.

We can do this in GCC, but I really don't think it's worth the
hassle.  Just consider the consequences of the change:

- exercise functional cross-compilation paths instead of native ones,
  if host is specified, even if the same as build

- implied prefix if target is specified, even if the same as host

That's it.  How bad can this be?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}