Re: more fun with m4_expand

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
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:

AC_FOO(m4_expand(AC_BAR))

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;
http://lists.gnu.org/archive/html/autoconf-patches/2008-11/msg00185.html.
 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
AC_INCLUDES_DEFAULT_QUOTED.

> 
> 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
documenting.

> 
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkksBLMACgkQ84KuGfSFAYCcpwCfQZu9wkfNd1uTAsAwfR1pyhpx
ebIAoMhrIXoNmhm9bySTXiUcPwV0A0xD
=QCZg
-----END PGP SIGNATURE-----