[Top][All Lists]

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

Re: more fun with m4_expand

From: Eric Blake
Subject: Re: more fun with m4_expand
Date: Tue, 25 Nov 2008 06:59:15 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20081105 Thunderbird/ Mnenhy/

Hash: SHA1

According to Paolo Bonzini on 11/24/2008 10:53 PM:
>> I'm going to sit on this patch a few more days before applying, unless I get 
>> a 
>> review.
> I think you can push the first.  Regarding the second, I have two ideas:
> 1) let's see if we can make the special case of requirements work.
>  Maybe expanding once with
> diversion to -1 using m4_divert_require, and once with normal diversion
> since the requirements will have been output already.  However that
> won't work with AS_REQUIRE.

Trust me, I'd like to get m4_require to play nicely with m4_expand, as
well.  The problem is the usage pattern:


If AC_BAR does and m4_require, even if the m4_expand is able to recognize
that, m4_expand cannot do anything about it except push it off to a
deferred location, because m4_expand is used inside argument collection
for AC_FOO.  But that deferred location had better be part of the epilogue
of AC_FOO, because the required text still needs to collected in the
correct order.  I might still be able to come up with something...

>  Can
> you send the non-working AS_ESCAPE patch?

I did;
 It fails a few tests where AC_INCLUDES_DEFAULT is involved, again
evidence that getting a m4_require to play nicely with m4_expand is
worthwhile, rather than that patch's attempt to add

> 2) but do we really need it?  AS_ESCAPE is a macro that will usually be
> used only by Autoconf mavens...

AS_ESCAPE lets you convert what would otherwise be an extra process to cat
an unquoted here-doc into an AS_ECHO of a double-quoted string.  Fewer
forks = faster configure scripts.  It's a very powerful idiom, worth

> BTW, is there a way to kill a diversion without outputting anything?
> Maybe you can add that to m4sugar.

m4_divert_text([KILL], [m4_undivert(diversion)])

But yes, maybe an m4_divert_discard(diversion) would be nice shorthand for
that.  Which brings up another weird semantic point of m4: m4_undivert
honors the current diversion, even during argument collection.  So my
current patch for m4_divert_text vs. m4_expand isn't quite right:

m4_expand([m4_divert_text([KILL], [m4_undivert(diversion)])])

should kill the text currently in diversion, but with the current state of
the patch, it routes it to the current diversion rather than KILL.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


reply via email to

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