Paul Brook - 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.

• From: Paul Brook
• To: binutils at sourceware dot org
• Cc: Michael Eager , Ian Lance Taylor , "Joseph S. Myers" , Daniel Jacobowitz , Paolo Bonzini , 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

• Follow-Ups:
  • Re: Updating top-level autoconf to 2.59
    * From: Alexandre Oliva
• References:
  • Re: Updating top-level autoconf to 2.59
    * From: Ian Lance Taylor
  • Re: Updating top-level autoconf to 2.59
    * From: Michael Eager