Autoconf <-> CVS M4 interactions

[Ralf Wildenhues]

[ Cc:ing bug-m4 mostly as FYI ]

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.

Hmm.  Interesting breakage: our build gives the new CVS M4 the frozen
installed file from M4-1.4.x to eat, which causes hiccups:

| $ make clean; make
[...]
| make[2]: Leaving directory `/tmp/autoconf/build/lib/m4sugar'
| autom4te_perllibdir='../../autoconf'/lib AUTOM4TE_CFG='../lib/autom4te.cfg'   
      ../bin/autom4te -B '..'/lib -B '../../autoconf'/lib         --language 
M4sh --cache '' ../../autoconf/bin/autoconf.as -o autoconf.in
| m4: Ill-formed frozen file

Adding --verbose reveals the breakage:

| autom4te: running: /tmp/m4/build/src/m4 --nesting-limit=1024 
--include=../../autoconf/lib --include=../lib 
--include=/tmp/prefix/share/autoconf --debug=aflq --fatal-warning 
--error-output=/tmp/am4tQ14446/traces.0t --trace=_m4_warn --trace=include 
--trace=m4_include --trace=m4_pattern_allow --trace=m4_pattern_forbid 
--reload-state=/tmp/prefix/share/autoconf/m4sugar/m4sh.m4f 
../../autoconf/bin/autoconf.as </dev/null >/tmp/am4tQ14446/output.0t

This is because lib/m4sugar/m4sh.m4f has not been built at the time
autoconf.as is built, so autom4te will prefer the installed (but old!)
frozen m4sh.m4f.  This is, by the way, even a bug without a major M4
upgrade, as autoconf.in should not contain outdated shell startup code.

The simplest patch I could come up with was the first one below.  OK?

For the other files that are created using $(MY_AUTOM4TE), the
corresponding frozen files in the build treee are created beforehand,
so they are safe for now.  (A safer change would be to add --melt to
$(MY_AUTOM4TE), but OTOH I think it's good to test the frozen files
where possible.)


With this patch, the remaining failures that I see with CVS M4 are some
autoupdate test failures:

|   12: tools.at:538       autoupdate
|   14: tools.at:597       autoupdating AC_PREREQ
|   15: tools.at:618       autoupdating AU_ALIAS
|   16: tools.at:644       autoupdating OLD to NEW
|   20: tools.at:743       autoupdating AC_FOREACH
|   21: tools.at:767       autoupdating with aclocal and m4_include

These all fail similarly (the other autoupdate-related tests don't fail
because we ignore stderr there):

| 12. tools.at:538: testing configure.ac~...
| ../../autoconf/tests/tools.at:559: autoupdate
| --- /dev/null   1970-01-01 00:00:01.000000000 +0200
| +++ /tmp/autoconf/build/tests/testsuite.dir/at-stderr 2006-06-16 
18:16:53.000000000 +0200
| @@ -0,0 +1,160 @@
| +m4: /tmp/aux16786/unm4.m4: 25: Warning: _au__undefine: undefined name: 
builtin
| +m4: /tmp/aux16786/unm4.m4: 26: Warning: _au__undefine: undefined name: 
changecom
| +m4: /tmp/aux16786/unm4.m4: 27: Warning: _au__undefine: undefined name: 
changequote
[...]

| +m4: /tmp/aux16786/unm4.m4: 198: Warning: _au__undefine: undefined name: 
undefine
| +m4: /tmp/aux16786/unm4.m4: 199: Warning: _au__undefine: undefined name: 
undivert
| 12. tools.at:538: 12. autoupdate (tools.at:538): FAILED (tools.at:559)

CVS M4 seems to spit out more warning that 1.4.x.  It looks like this
may be us undefining macros that are simply aren't defined, but I am
really really uncertain about the second patch below (it does pass the
test suite with both CVS M4 and 1.4.1, but I won't install it unless
someone confirms that it is ok).

FWIW, I also noticed that CVS M4 -- when built with shared libraries
enabled at least -- is significantly slower than 1.4.x.

Cheers,
Ralf

        * bin/Makefile.am (autoconf.in): Use `--melt' for autom4te,
        in order to avoid picking up an older installed frozen m4sh.m4f.
        Besides an outdated shell startup, this could have been created
        by an earlier M4 version with incompatible frozen file format.

Index: bin/Makefile.am
===================================================================
RCS file: /cvsroot/autoconf/autoconf/bin/Makefile.am,v
retrieving revision 1.24
diff -u -r1.24 Makefile.am
--- bin/Makefile.am     24 May 2005 06:14:27 -0000      1.24
+++ bin/Makefile.am     16 Jun 2006 16:41:56 -0000
@@ -52,8 +52,11 @@
        -e 's|@address@hidden|Generated from address@hidden; do not edit by 
hand.|g'
 
 # autoconf is written in M4sh.
+# We need --melt here, because this target does not depend on the frozen
+# files below lib/m4sugar, and autom4te may thus pick up a frozen m4sh.m4f
+# from an earlier installation below the same $(prefix).
 autoconf.in: $(srcdir)/autoconf.as $(m4sh_m4f_dependencies)
-       $(MY_AUTOM4TE) --language M4sh --cache '' $(srcdir)/autoconf.as -o $@
+       $(MY_AUTOM4TE) --language M4sh --cache '' --melt $(srcdir)/autoconf.as 
-o $@
 
 ## All the scripts depend on Makefile so that they are rebuilt when the
 ## prefix etc. changes.  It took quite a while to have the rule correct,



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

Index: bin/autoupdate.in
===================================================================
RCS file: /cvsroot/autoconf/autoconf/bin/autoupdate.in,v
retrieving revision 1.61
diff -u -r1.61 autoupdate.in
--- bin/autoupdate.in   7 Apr 2006 18:25:30 -0000       1.61
+++ bin/autoupdate.in   16 Jun 2006 17:09:35 -0000
@@ -207,7 +207,7 @@
   foreach (sort keys %m4_builtins)
     {
       print $m4save_m4 "_au__save([$_])\n";
-      print $unm4_m4   "_au__undefine([$_])\n";
+      print $unm4_m4   "_au_m4_ifdef([$_], [_au__undefine([$_])])\n";
       print $m4_m4     "_au__restore([$_])\n";
     }
 }