Re: m4_wrap behavior

[Stepan Kasal]

Hello,

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.

I returned back to my original opinion:

Autoconf doesn't really depend on m4_wrap order.  The macros
m4_diversion_push and m4_diversion_pop are slightly oddly implemented
and used.  If foo_init is changing the base diversion, there is no
reson to push the previous on the stack.

This can be fixed easily.  Patch is attached, it passes make check.
(A more thourough cleanup of the implementation is due after the
release.)

I don't thing we should engage in the politics of FIFO-endian vs.
LIFO-endian, because:
- other than the above unfortunate issue, neither Autoconf nor
  Automake care
- I don't think the POSIX decision is so bad that we shall go to
  streets

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.

(This gives us a chance to stay aside.  It is possible that a few
years later, Autoconf will be routinely used with GNU m4 >= 2.0 or
with BSD m4, which both follow the standard; the non-standard
behaviour will become history.)

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

Have a nice day,
        Stepan Kasal

autoconf-20060616-m4wrap.patch
Description: Text document