[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in gnulib-tools prevents bison from bootstrapping
Re: Bug in gnulib-tools prevents bison from bootstrapping
Fri, 31 Aug 2007 06:50:07 -0600
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20070728 Thunderbird/22.214.171.124 Mnenhy/0.7.5.666
-----BEGIN PGP SIGNED MESSAGE-----
[reviving an old thread, replies can probably drop bug-autoconf]
According to Noah Misch on 6/23/2007 8:54 PM:
>> On 23 Jun 2007, at 06:25, Eric Blake wrote:
>>>> My system has a /usr/bison/m4 and a /usr/bin/gm4, but no
>>>> /usr/local/bin/gm4, because later version of M4 odes not install it.
>>> The current algorithm is in autoconf's m4/m4.m4:
>>> AC_PATH_PROGS([M4], [gm4 gnum4 m4], [m4])
>>> AC_CACHE_CHECK([whether m4 supports accurate traces],
>>> In other words, during configuration, autoconf finds the first
>>> program on
>>> your PATH named gm4, gnum4, and then m4, which also meets the minimum
>>> requirements of m4 1.4.5 or later. If you have suggestions for a
>>> algorithm, we'd like to know about it.
> This sounds like a fine algorithm, but it not the one that the above code
> implements. Rather, the code finds the first program so-named and checks
> whether that one program meets the version requirement. It does not continue
> the search upon rejecting a candidate.
The attached patch implements the above algorithm. However, before I
apply it, I wonder if it is time to make a documented public macro that
makes this idiom kosher, rather than using an internal macro.
Note that _AC_PATH_PROG_FEATURE_CHECK already has a bug in its current
usage in programs.m4 - it is currently only used by AC_PROG_GREP and
AC_PROG_SED, both of which invoke it inside AC_CACHE_CHECK. Therefore,
its attempt to do AC_SUBST([$1]) is useless - if you run ./configure -C
with the program variable unset, the first run will set the variable, but
the second run will leave it unset. Fortunately, both AC_PROG_GREP and
AC_PROG_SED (and my patch below) work around this bug, by re-calling
AC_SUBST(variable) after the cache context ends.
I'm thinking a public macro should look like:
# AC_PATH_PROG_FEATURE_CHECK(VARIABLE, PROGNAME-LIST, MSG,
# FEATURE-TEST, [PATH=$PATH])
# Cache a search for a program, using MSG as in AC_CACHE_CHECK.
# If VARIABLE is set, use it without any questions. Otherwise,
# call FEATURE_TEST repeatedly with $ac_path_VARIABLE set to the
# name of a program in PROGNAME-LIST found in PATH. FEATURE-TEST
# must set $ac_cv_path_VARIABLE to the path of an acceptable
# program, or else _AC_PATH_PROG_FEATURE_CHECK will report that
# no acceptable program was found, and abort. If a suitable
# $ac_path_VARIABLE is found in the FEATURE-TEST macro, it can
# set $ac_path_VARIABLE_found=':' to accept that value without
# any further checks. On success, VARIABLE will contain the
# final program found, and will be AC_SUBST'd.
2007-08-30 Eric Blake <address@hidden>
Improve M4 path searching during configure.
* m4/m4.m4 (AC_PROG_GNU_M4): Don't stop searching until working m4
is found. Make M4 precious.
* configure.ac (M4): AC_PROG_GNU_M4 now exits on failure.
* configure: Regenerate.
Don't work too hard, make some time for fun as well!
Eric Blake address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
RCS file: /sources/autoconf/autoconf/configure.ac,v
retrieving revision 1.89
diff -u -p -r1.89 configure.ac
--- configure.ac 20 Jul 2007 23:11:50 -0000 1.89
+++ configure.ac 31 Aug 2007 12:46:30 -0000
@@ -79,12 +79,9 @@ AC_PATH_PROG([EXPR], [expr])
# We use an absolute name for GNU m4 so even if users have another m4 first in
# their path, the installer can configure with a path that has GNU m4
-# first and get that path embedded in the installed autoconf and
+# on it and get that path embedded in the installed autoconf and
# autoheader scripts.
-if test x"$ac_cv_prog_gnu_m4" != xyes; then
- AC_MSG_ERROR([GNU M4 1.4.5 or later is required; 1.4.8 is recommended])
## ----------- ##
## Man pages. ##
RCS file: /sources/autoconf/autoconf/m4/m4.m4,v
retrieving revision 1.7
diff -u -p -r1.7 m4.m4
--- m4/m4.m4 2 Feb 2007 14:07:38 -0000 1.7
+++ m4/m4.m4 31 Aug 2007 12:46:30 -0000
@@ -1,4 +1,4 @@
-# m4.m4 serial 3
+# m4.m4 serial 4
dnl Copyright (C) 2000, 2006, 2007 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -12,20 +12,19 @@ dnl with or without modifications, as lo
# Also, check whether --error-output (through 1.4.x) or --debugfile (2.0)
# is supported, and AC_SUBST M4_DEBUGFILE accordingly.
-[AC_PATH_PROGS([M4], [gm4 gnum4 m4], [m4])
-AC_CACHE_CHECK([whether m4 supports accurate traces], [ac_cv_prog_gnu_m4],
-dnl Creative quoting here to avoid raw dnl and ifdef in configure.
-if test x"$M4" != x \
- && test -z "`echo if'def(mac,bug)d'nl | $M4 --trace=mac 2>&1`" ; then
-if test $ac_cv_prog_gnu_m4 = yes ; then
+ [AC_ARG_VAR([M4], [Location of GNU M4 1.4.5 or later. Defaults to the first
+ program of `m4', `gm4', or `gnum4' on PATH that meets Autoconf needs.])
+ AC_CACHE_CHECK([for GNU M4 that supports accurate traces], [ac_cv_path_M4],
+ [dnl FIXME _AC_PATH_PROG_FEATURE_CHECK should be made public
+ _AC_PATH_PROG_FEATURE_CHECK([M4], [m4 gm4 gnum4],
+ [dnl Creative quoting here to avoid raw dnl and ifdef in configure.
+ test -z "`echo if'def(mac,bug)d'nl | $ac_path_M4 --trace=mac 2>&1`" \
+ && ac_cv_path_M4=$ac_path_M4 ac_path_M4_found=:])])
AC_CACHE_CHECK([how m4 supports trace files], [ac_cv_prog_gnu_m4_debugfile],
- [case `$M4 --help < /dev/null 2>&1` in
- *debugfile*) ac_cv_prog_gnu_m4_debugfile=--debugfile ;;
- *) ac_cv_prog_gnu_m4_debugfile=--error-output ;;
- AC_SUBST([M4_DEBUGFILE], $ac_cv_prog_gnu_m4_debugfile)
+ [case `$M4 --help < /dev/null 2>&1` in
+ *debugfile*) ac_cv_prog_gnu_m4_debugfile=--debugfile ;;
+ *) ac_cv_prog_gnu_m4_debugfile=--error-output ;;
+ AC_SUBST([M4_DEBUGFILE], [$ac_cv_prog_gnu_m4_debugfile])
- Re: Bug in gnulib-tools prevents bison from bootstrapping,
Eric Blake <=