-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[dropping bug-m4, adding autoconf-patches]
According to Stepan Kasal on 6/13/2006 2:46 PM:
>
> The biggest problem is this:
>
> m4_init contains:
> m4_divert_push([KILL])
> m4_wrap([m4_divert_pop([KILL])[]])
>
> AS_INIT contains:
> m4_init
> ...
> m4_divert_push([BODY])
> m4_wrap([m4_divert_pop([BODY])[]])
>
> That clearly depends on the LIFO order of m4_wrap.
...
>
> Actually, the code of AS_INIT really looks nice and the building of
> one package on top of another naturally works with the LIFO order.
> It seems to be pity that m4 standrdized for FIFO.
>
Well, how about a patch to m4sugar that forces m4_wrap to always be LIFO,
and documents it as such, regardless of the underlying m4wrap
implementation? I'm not sure if we want this before 2.60 (on the other
hand, we will need it if m4 2.0 comes out before autoconf 2.61).
Borrowing from my earlier mail in this thread:
2006-06-13 Eric Blake <ebb9@xxxxxxx>
* lib/m4sugar/m4sugar.m4 (_m4_wrap_level): New helper macro.
(m4_wrap): Reimplement to guarantee LIFO order, even if m4wrap is
in POSIX-specified FIFO order.
* doc/autoconf.texi (Redefined M4 Macros): Document that m4_wrap
is always LIFO.
- --
Life is short - so eat dessert first!
Eric Blake ebb9@xxxxxxx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEj4jr84KuGfSFAYARAoSfAKDSRsOSLCJ4DzhkGW3blyj1aT89tQCfSw2E
eJSKXVDR5NzYTBG/l3/4Xxw=
=v52f
-----END PGP SIGNATURE-----
Index: lib/m4sugar/m4sugar.m4
===================================================================
RCS file: /sources/autoconf/autoconf/lib/m4sugar/m4sugar.m4,v
retrieving revision 2.98
diff -u -p -r2.98 m4sugar.m4
--- lib/m4sugar/m4sugar.m4 5 Jun 2006 08:18:33 -0000 2.98
+++ lib/m4sugar/m4sugar.m4 14 Jun 2006 03:53:22 -0000
@@ -561,6 +561,38 @@ m4_define([m4_undefine],
m4_builtin([undefine], $@)])
+# _m4_wrap_level
+# --------------
+# Track the current recursion level of m4. Nested calls to m4_wrap
+# are processed in LIFO order on the next recursion level after the
+# current input level has been expanded.
+m4_define([_m4_wrap_level], [0])
+
+
+# m4_wrap(TEXT)
+# -------------
+# Add TEXT to the beginning of the current recursion level of wrapped
+# text, to be expanded when the current input is exhausted. This
+# enforces LIFO ordering, even though POSIX requires the underlying
+# m4wrap to have FIFO ordering; and works whether the underlying m4wrap
+# is FIFO (GNU m4 2.0) or LIFO (GNU m4 1.4.x). It also forbids excess
+# arguments, since POSIX does not guarantee how they are handled.
+#
+# This relies on intermediate macros of the form _m4_wrap<n> for
+# storing the LIFO stack, and only calls the real m4wrap once per
+# recursion level.
+m4_define([m4_wrap],
+[m4_if(m4_eval([$# > 1]), [1],
+ [m4_fatal([$0: too many arguments])])dnl
+m4_ifdef([_m4_wrap]_m4_wrap_level,
+ [m4_define([_m4_wrap]_m4_wrap_level,
+ [$1]m4_defn([_m4_wrap]_m4_wrap_level))],
+ [m4_builtin([m4wrap], [m4_define([_m4_wrap_level],
+ m4_incr(_m4_wrap_level))dnl
+_m4_wrap]_m4_wrap_level)dnl
+m4_define([_m4_wrap]_m4_wrap_level, [$1])])])
+
+
## -------------------------- ##
## 7. Implementing m4 loops. ##
## -------------------------- ##
Index: doc/autoconf.texi
===================================================================
RCS file: /sources/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.1042
diff -u -p -r1.1042 autoconf.texi
--- doc/autoconf.texi 8 Jun 2006 17:25:10 -0000 1.1042
+++ doc/autoconf.texi 14 Jun 2006 03:53:26 -0000
@@ -9593,7 +9593,9 @@ provide extended regular expression synt
@defmac m4_wrap (@var{text})
@msindex{wrap}
-This macro corresponds to @code{m4wrap}.
+This macro corresponds to @code{m4wrap}. However, this macro fails if
+there is more than one argument, and multiple invocations are collected
+in last-in-first-out order, in order to ease stacking paradigms.
You are encouraged to end @var{text} with @samp{[]}, so that there are
no risks that two consecutive invocations of @code{m4_wrap} result in an
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
