[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_m4([indir])
m4_rename_m4([len])
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_ifdef([m4pawr],
+[m4_rename([m4pawr], [m4_wrap])m4_undefine([m4wrap])],
+[m4_rename([m4wrap], [m4_wrap])])
m4_rename_m4([maketemp])
m4_rename([patsubst], [m4_bpatsubst])
m4_undefine([popdef])
- Re: m4_wrap behavior,
Eric Blake <=
- Re: m4_wrap behavior, Paul Eggert, 2006/06/16
- Re: m4_wrap behavior, Ralf Wildenhues, 2006/06/16
- Re: m4_wrap behavior, Stepan Kasal, 2006/06/16
- Re: m4_wrap behavior, Ralf Wildenhues, 2006/06/19
- Re: m4_wrap behavior, Paul Eggert, 2006/06/19
- Re: m4_wrap behavior, Ralf Wildenhues, 2006/06/20
- Re: m4_wrap behavior, Eric Blake, 2006/06/20
- Re: m4_wrap behavior, Paul Eggert, 2006/06/20