Re: Autoconf <-> CVS M4 interactions

[Eric Blake]

> 
> M4 upgrade scenario:
> 
> - You are working on Autoconf; the build tree has the same --prefix
>   as an earlier version of Autoconf that is already installed there.
> - The earlier Autoconf version used M4 1.4.x as underlying work horse.
> - Now (sometime in the future) you are just apt to try out, say,
>   just-released M4-2.0 (or, in the present, you're crazy enough to try
>   CVS M4 ;-)  so that's what you use for the new Autoconf.

Indeed, I will not allow CVS M4 to be released as m4-2.0 until I am
satisfied that this very scenario works without regressions (running
an installed autoconf that was configured with m4 1.4.x but now uses
m4 2.0).  We certainly aren't there, yet.  For one thing, CVS m4 needs
to be taught that when a version 1 frozen file is parsed in, it needs to
initialize the syntax table to sane defaults (done normally by the
'S' command in version 2 frozen files).  But right now, CVS m4 cannot
properly read files frozen by m4 1.4.x.

> 
>       * bin/autoupdate.in (handle_autoconf_macros): Do not
>       _au__undefine the builtins that aren't defined, before restoring
>       the original ones.  Fixes warnings issues by CVS M4.

That is safe, but I'd rather figure out the underlying cause of why
CVS m4 is not defining builtins in the first place.

-- 
Eric Blake