Re: m4_wrap behavior

[Stepan Kasal]

Hello,

On Tue, Jun 13, 2006 at 09:47:43PM +0200, Ralf Wildenhues wrote:
> FWIW, there are only a handful of uses of m4_wrap in Autoconf >= 2.59.
> All look like they don't care about the order, [...]

I looked at the ocurrences of m4_wrap,and I'm afraid you are not
right.

There are several instainces of

m4_wrap([m4_divert_text([WHERE], [....])])

which indeed do not interact, because there are never two such calls
for the same diversion in one file.

m4_init contains two calls to m4_wrap (one does m4_divert_pop and the
other checks whether the divert stack is empty), but that is
trivially fixable by joining them.

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.

And there are more occurences; the call graph looks like this:

m4_init --> AS_INIT --> AT_INIT
m4_init --> several tests in m4sugar.at

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.

But, of course, that can also be easily fixed: all those
m4_divert_push call will be changed to m4_divert.  No, we are not
losing any consistency check that way: the ending check that the
stack is empty is enough.

The obvious consequence is that Autoconf <= 2.60 won't work with GNU
m4 2.0.
Luckily, there is no risk of installing a broken version of autoconf;
the build will break, since autoconf.as is a m4sh script.

Have a nice day,
        Stepan