Re: Bug in gnulib-tools prevents bison from bootstrapping

[Noah Misch]

On Sat, Jun 23, 2007 at 11:06:02AM +0200, Hans Aberg wrote:
> 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.

Just use `./configure M4=/usr/local/bin/m4' to make Autoconf skip the search and
use the m4 you want.

> >m4 will install as /usr/local/bin/gm4 if you use the --program- 
> >prefix=g
> >option at m4's configure time.
> 
> Thank you for the info. But I think it is correct to not have gm4  
> installed these days:
> 
> I have a vague memory that once (?) there was an independent m4, and  
> GNU making their own version gm4. The development of m4 was dropped,  
> so that GNU could take over the name m4.

M4 is a standard tool from the early Unix days; at a minimum, we have the
original implementation, PD M4, and GNU M4.  Some installers choose to prefix
GNU program names with `g' on systems that began with non-GNU tools.  There has
never been a reason to do this on the GNU system, where the GNU program provides
the principal implementation.

> >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  
> >better
> >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.