committed: PR ada/14350 fix

[bonzini]

Paolo Bonzini wrote:

> Now that it has become a monster program with all sorts of
> dependencies between the macros, sh and m4 are a poor implementation
> choice.

You're probably right, but I think that having to deal with the legacy 
of thousands of configure scripts, some of which extremely complex such 
as Emacs, gcc or glibc (only to remain within the FSF realm), I do not 
see a way to move away from sh and m4.  At least without requiring a 
reengineering work which is much bigger than what is required by 
Autoconf 2.5x.

As to the naming of autoconf 2.5x, I believe that Akim Demaille wanted 
to move much further for Autoconf 3, but did not understand (at least 
before it was too late) how slow the autoconf development cycle must be, 
and how slowly configure scripts generated with newer versions spread.  
Indeed the problem with autoconf's development cycle is that portability 
problems usually do not happen at autoconf users' machines, but a level 
further: at configure script users' machines.  This slows down 
considerably the reporting of bug reports.

Paolo