[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: m4_wrap behavior

From: Eric Blake
Subject: Re: m4_wrap behavior
Date: Tue, 13 Jun 2006 21:56:27 -0600
User-agent: Thunderbird (Windows/20060516)

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  <address@hidden>

        * 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             address@hidden

Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -

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_if(m4_eval([$# > 1]), [1],
+       [m4_fatal([$0: too many arguments])])dnl
+         [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_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})
-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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]