[Top][All Lists]

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

Re: m4_wrap behavior

From: Stepan Kasal
Subject: Re: m4_wrap behavior
Date: Thu, 15 Jun 2006 15:30:06 +0200
User-agent: Mutt/

Hello Paul and Eric,

  in short, I have changed my mind, and I think we should install
Eric's patch.

On Thu, Jun 15, 2006 at 05:47:04AM -0600, Eric Blake wrote:
> According to Paul Eggert on 6/15/2006 1:28 AM:
> > Sorry, I'm lost.  If Autoconf doesn't need a wrapper, then why does a
> > build break with a 2.0-like m4?

I apologize for the confusion.  Let me correct it:

Autoconf 2.60 requires LIFO, and will break with m4 2.0.

The most evil scenario is the one described by Ralf:
m4 < 2.0 is used to build Autoconf 2.60, but then m4 is upgraded to
2.0 and autoconf stops working.

I can see two ways to fix the problem:

1) autoconf will check for m4 >= 2.0 at startup and will refuse to
run with m4 >= 2.0

2) m4_wrap in m4sugar.m4 will ensure the LIFO order.

The (1) is slightly more reliable, because it protects us from other
possible incompatibilities with m4-2.0, not yet known.

But (2) is less intrusive, and the implementation is right at our
hand, written by Eric:

> I already provided such a patch, that guarantees LIFO order in m4_wrap

On a second thought, this is probably the best solution, let's
accept a variant of this patch (I have not reviewed it yet, sorry).

But I don't think we should document that m4_wrap is LIFO, because it
may not be necessarily true.

In future, I think some code around m4_diversion_push and _pop should
be cleaned up.  The Autoconf itself will then become independent on 
the fact that m4_wrap is LIFO.  Than we can remove the LIFO wrapper

I don't think we need to discuss about the above dream, but please
let the question open: do not document that m4_wrap is LIFO.

I hope this mail is less confusing than the previous one.


reply via email to

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