[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: Fri, 16 Jun 2006 01:16:28 +0000

> Something like that sounds fine, but I worry about
> having m4_wrap behave differently from M4's m4wrap.
> That's an unhealthy naming convention.

Agreed, although several other m4sugar macros are defined
to have improved semantics or limitations beyond the
underlying m4.

> Also, I worry that non-Autoconf uses of m4_wrap will break with the
> new implementation, due to some obscure token-pasting or whatever
> (sorry, I'm waving my hands here).

Actually, I'm pretty confident that my patch matched native behavior;
between Solaris m4 (FIFO) and m4 1.4.4a (LIFO), and two versions
of my patch, I was able to make either m4 match the behavior
of the other regardless of token-pasting and m4wrap recursion
scenarios.  But that's for a reviewer to determine :)

> How about this idea instead?
>  * Leave m4_wrap alone.
>  * Use something like Eric's patch to define a new macro m4_wrap_fifo.
>  * Modify Autoconf to use m4_wrap_fifo rather than m4_wrap.
>  * Document m4_wrap_fifo.
>  * Document that m4_wrap isn't portable.

Wouldn't that be m4_wrap_lifo for autoconf 2.60, if we want
minimal code changes to the rest of autoconf?

Speaking of which, here is an idea towards a simpler
m4-2.0-proof definition of m4_wrap, with less overhead
per use of m4_wrap than my earlier patch (no ChangeLog
provided, as this is just an idea for now).

Eric Blake

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      16 Jun 2006 00:57:52 -0000
@@ -139,7 +139,15 @@ m4_rename_m4([index])
 m4_rename([m4exit], [m4_exit])
-m4_rename([m4wrap], [m4_wrap])
+# m4 1.4.x provided only m4wrap with LIFO order.  m4 2.0 will provide
+# m4wrap with FIFO order, and m4parw with LIFO order.  For autoconf 2.60,
+# we depend on LIFO order internally, but document that m4_wrap has
+# indeterminate order.  Then, in a future release of autoconf, we can
+# define m4_wrap_fifo and m4_wrap_lifo, and quit using m4_wrap.
+[m4_rename([m4pawr], [m4_wrap])m4_undefine([m4wrap])],
+[m4_rename([m4wrap], [m4_wrap])])
 m4_rename([patsubst], [m4_bpatsubst])

reply via email to

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