autoconf-patches
[Top][All Lists]
Advanced

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

Re: m4_wrap behavior


From: Ralf Wildenhues
Subject: Re: m4_wrap behavior
Date: Mon, 19 Jun 2006 21:18:08 +0200
User-agent: Mutt/1.5.11+cvs20060403

Hello,

* Stepan Kasal wrote on Fri, Jun 16, 2006 at 03:51:32PM CEST:
> On Fri, Jun 16, 2006 at 01:42:57PM +0200, Ralf Wildenhues wrote:
> > * Paul Eggert wrote on Fri, 16 Jun 2006 04:08:24 -0700:
> > > address@hidden (Eric Blake) writes:
> > > > Speaking of which, here is an idea towards a simpler
> > > > m4-2.0-proof definition of m4_wrap, with less overhead
> ...
> > > That suggestion looks good to me (needs a documentation update for
> ...
> > Me too.
> 
> well, it might be difficult to overweight this, but I do not agree.

The short story:

I think Stepan's patch should be installed as well as the one below
(modulo review on my wording), as I think it is the better solution.

Long story:

Shortly after Stepan posted his patch, he told me he was convinced
(no, I didn't convince him ;-) that Eric's patch should be applied,
because
- it was very obvious that it would not break existing code
- and it was very very likely that it would work with M4-2.0.

I bought that at first.  Only to rethink again afterwards:
I agree with Stepan that
- Autoconf should not engage in FIFO/LIFO politics of m4wrap.

Why?  Not only will GNU M4 1.4 differ from 2.0, but it also differs from
BSD M4 and most if not all other M4s; and POSIX M4.  And the m4parw hack
won't save users of BSD M4.  And IIRC there were some BSD efforts to get
recent Autoconf working with its M4 anyway, so let's not ignore that.
Last but not least m4parw is a really ugly name.  ;-)

So, if Autoconf shall control order, then it better do so with a set of
macros m4_wrap_lifo, m4_wrap_fifo, which could be made to work with any
M4 out there.  But that would be a new feature, so we don't do that now.

What about existing uses of m4_wrap/m4wrap?  Well, the net turns up very
few of them:
- one in glibc, which is a copy of a couple of m4sh code lines, and
- another one in bison.

Both look harmless to me.  So, I think this argument:

> Autoconf doesn't really depend on m4_wrap order.

is better than the ones for m4parw.  And finally, of course,
this one made me buy it:

> Will you buy that, if I pack a free chocolate with it?  :-)

;-)

> Thus I propose to install the attached patch, plus document that the
> order of m4_wrap is not defined, and follows the politics of the
> underlying m4.

I propose this documentation along with it, and, given absence of
comments, will apply both patches together in a day or two.

Cheers,
Ralf

        * doc/autoconf.texi (Redefined M4 Macros): Mention that the
        order in which m4_wrap's are unwrapped is undefined (due to
        the underlying m4wrap).
        * NEWS: Update.

Index: doc/autoconf.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.1051
diff -u -r1.1051 autoconf.texi
--- doc/autoconf.texi   16 Jun 2006 20:38:03 -0000      1.1051
+++ doc/autoconf.texi   19 Jun 2006 18:55:00 -0000
@@ -9651,6 +9651,9 @@
 m4_wrap([foo])
 @result{}FOOBAR
 @end example
+
address@hidden
+except that the order in which the stored texts are reread is undefined.
 @end defmac
 
 @defmac m4_undefine (@var{macro})
Index: NEWS
===================================================================
RCS file: /cvsroot/autoconf/autoconf/NEWS,v
retrieving revision 1.381
diff -u -r1.381 NEWS
--- NEWS        6 Jun 2006 06:18:40 -0000       1.381
+++ NEWS        19 Jun 2006 19:15:59 -0000
@@ -1,5 +1,9 @@
 * Major changes in Autoconf 2.59e
 
+** Autoconf does not depend on the order in which M4 rereads the m4wrap 
+  invocation any more, to work with a future GNU M4 which may implement
+  the order required by Posix.  Consequently, m4_wrap order is undefined.
+
 * Major changes in Autoconf 2.59d
 
   Released 2006-06-05, by Ralf Wildenhues.




reply via email to

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