Re: autoconf 2.59

[Akim Demaille]

 > Akim Demaille <address@hidden> writes:
 >> I'm not sure what's the best solution here.

 > One possibility is to have a bootstrap procedure, which builds
 > autoconf from the system-available tools, and then rebuilds autoconf
 > using the newly generated autoconf.  Just like GCC, I'm afraid.

Bleah.

This is only a partial solution, but I fail to see any interest in
having M4sh used in tests/wrapper.  As simple shell script would work
fine.

 > There's a similar problem with Bison.  (Bison has a bootstrap
 > procedure, which is better than Autoconf; but it's not yet complete,
 > since it doesn't use the newly built Bison to compile its own .y
 > files.)

 > Doing this all would take some work.  In the short run, perhaps the
 > first step should be to do the following steps before generating a new
 > version of Autoconf:

 > * Build and install Autoconf.
 > * make maintainer-clean
 > * (wave your magic wand here, to build stuff that needs building by hand)
 > * make dist

That's what I usually do, but... wrapper.in is not in maintainer-clean :)

 > The "wave your magic wand" step can eventually be written down,
 > automated, and codified into a bootstrap procedure.

Another, non exclusive, approach, would be to have make distcheck
check that embedded Autoconf products have the same version as the
current Autoconf.