This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Updating top-level autoconf to 2.59
- From: Paul Brook <paul at codesourcery dot com>
- To: binutils at sourceware dot org
- Cc: Michael Eager <eager at eagercon dot com>, Ian Lance Taylor <iant at google dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Daniel Jacobowitz <drow at false dot org>, Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>, gcc-patches at gcc dot gnu dot org, newlib at sourceware dot org
- Date: Thu, 8 Feb 2007 17:10:20 +0000
- Subject: Re: Updating top-level autoconf to 2.59
- References: <20070111225346.GA1335@nevyn.them.org> <m37iuslmod.fsf@localhost.localdomain> <45CB5453.3080109@eagercon.com>
On Thursday 08 February 2007 16:48, Michael Eager wrote:
> Ian Lance Taylor wrote:
> > "Joseph S. Myers" <joseph@codesourcery.com> writes:
> >> * If you want to build an explicitly cross tool despite host == target,
> >> or act like you are cross compiling despite build == host, or build a
> >> native tool (i.e. one using the native directory layout and installed as
> >> plain "gcc") despite host != target, or act like you aren't cross
> >> compiling (so can run execute tests for $host) despite build != host,
> >> these should be determined by explicit configure options; not by which
> >> of build, host and target where specified explicitly and which were
> >> defaulted. (And not by older autoconf's experiments to see if it can
> >> execute a program built for the host.)
> >
> > I completely agree that this is how it should work. Unfortunately,
> > this is not how autoconf {2.x,x>13} works. I don't agree with a
> > number of the decisions made by the autoconf maintainers. However, I
> > do think that as long we use autoconf, there is some benefit to be
> > gained by following autoconf's default behaviour.
>
> I'll stick my toe into this discussion.
>
> Much of the discussion seems to be about how autoconf should guess what
> the user intended by --host, --build, --target. When --host or --build
> is omitted, autoconf makes guesses about what the user might have
> specified, then uses these guesses (as well as the exec test) to determine
> whether this is a native or cross build. The result is that the user
> tries to guess how autoconf is trying to guess what the user means.
I agree. Same applies for automated build systems. Instead of just saying what
you want, you have to reverse-engineer the autoconf guessing logic.
Paul