[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Autoconf <-> CVS M4 interactions
Autoconf <-> CVS M4 interactions
Fri, 16 Jun 2006 19:13:58 +0200
[ 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: 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=/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
../../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
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
| @@ -0,0 +1,160 @@
| +m4: /tmp/aux16786/unm4.m4: 25: Warning: _au__undefine: undefined name:
| +m4: /tmp/aux16786/unm4.m4: 26: Warning: _au__undefine: undefined name:
| +m4: /tmp/aux16786/unm4.m4: 27: Warning: _au__undefine: undefined name:
| +m4: /tmp/aux16786/unm4.m4: 198: Warning: _au__undefine: undefined name:
| +m4: /tmp/aux16786/unm4.m4: 199: Warning: _au__undefine: undefined name:
| 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.
* 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.
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
# 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
## 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.
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";
- Autoconf <-> CVS M4 interactions,
Ralf Wildenhues <=