autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_CHECK_TOOL changes, take 2


From: Ralf Corsepius
Subject: Re: AC_CHECK_TOOL changes, take 2
Date: Mon, 22 Mar 2004 10:13:26 +0100

On Mon, 2004-03-22 at 05:57, Paul Eggert wrote:
> Ralf Corsepius <address@hidden> writes:
> 
> >> I don't offhand see the harm of supporting "configure FOO" as a
> >> synonym for "configure --build=FOO".
> > It would be a behavioral change: 
> > It currently is a synonym to "configure --host=FOO"
> 
> Really? 

Well, I actually fail to see how $build is useful at all.

Configuration lookup tables is the only thing I could imagine some
people to be tempted to use.

Another usage that had worked to some extend is target-native builds:
CC=crosscompiler configure --build=cross-target --host=cross-target

>  I thought that had been fixed. 

AFAIS, things actually are worse:

Example: Given this configure.in:
---- snip ----
AC_INIT(Makefile.am)
AM_INIT_AUTOMAKE(autotest,0.1)
AC_CANONICAL_HOST
echo "BUILD : $build $build_alias"
echo "HOST  : $host $host_alias"
echo "TARGET: $target $target_alias"
AC_PROG_CC
AC_CHECK_TOOL(RANLIB,ranlib)
AC_OUTPUT(Makefile)
----  snip ----

With autoconf-2.13/automake-1.4p6:
./configure sparc
BUILD : NONE
HOST  : sparc-sun-sunos4.1.1 sparc
TARGET: NONE
checking for gcc... (cached) gcc
...
checking build system type... sparc-sun-sunos4.1.1
checking for ranlib... (cached) ranlib
...
Note: the native tools are being checked, $host and $host_alias refer to
sparc*, $build and $target are NONE, $build_alias and $target_alias are
unset.


With autoconf-2.59/automake-1.8.2:
./configure sparc
configure: WARNING: you should use --build, --host, --target
...
checking build system type... sparc-sun-sunos4.1.1
checking host system type... sparc-sun-sunos4.1.1
BUILD : sparc-sun-sunos4.1.1 sparc
HOST  : sparc-sun-sunos4.1.1 sparc
TARGET: sparc sparc
checking for sparc-gcc... no
checking for gcc... gcc
...
checking for sparc-ranlib... no
checking for ranlib... ranlib
...
Note: The host-tools are being checked => there is no backward
compatibility at all.

Checking the host-tools means cross-compilation, i.e. is equivalent to
setting --host.

However, I don't understand why $build is set to $host, because I don't
under stand what --build=sparc --host=sparc is supposed to mean on an
i686-pc-linux-gnu system.

IMO, this behavior is broken.

>  If we're going to change
> anything in this area, we should change this too.  Autoconf should
> support the GNU coding standards.

> > I don't recall any attempt to get the GCS changed wrt. --host.
> 
> I went back and look at the old email.  Here's Akim's original
> proposal for GCS changes to autoconf-maintainers:
> 
> http://mail.gnu.org/archive/html/autoconf-maintainers/2002-11/msg00000.html
> 
> Tom Tromey and Pavel Roskin commented on this, and then Akim proposed
> the following to RMS:
> 
> http://mail.gnu.org/archive/html/autoconf-maintainers/2002-11/msg00010.html
> 
> RMS immediately responded that "configure FOO" should be equivalent to
> "configure --build=FOO":

Do you think he is competent wrt. this topic?

> http://mail.gnu.org/archive/html/autoconf-maintainers/2002-11/msg00011.html
> 
> and I (gulp -- I'd forgotten all this until just now :-) reworked
> Akim's proposal to the text that eventually went into the GNU coding
> standards:
> 
> http://mail.gnu.org/archive/html/autoconf-maintainers/2002-11/msg00014.html
> 
> Unfortunately this change doesn't seem to have propagated into
> Autoconf yet.  Probably Akim was worried about backward compatibility
> issues.  But it's time to do it now, if we're going to do anything.

Thanks for digging the links out, I'll try to read them sometime later today.

BTW: I guess you might want to read this http://airs.com/ian/configure

Though this text is a bit dated it is still the only document I know
that describes Cross-building.

Ralf






reply via email to

[Prev in Thread] Current Thread [Next in Thread]