[Top][All Lists]

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

Re: preparation for expand-before-require warning

From: Eric Blake
Subject: Re: preparation for expand-before-require warning
Date: Wed, 21 Jan 2009 06:30:58 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20081209 Thunderbird/ Mnenhy/

Hash: SHA1

According to Paolo Bonzini on 1/21/2009 1:01 AM:
>> m4_defun([a],[A])
>> m4_defun([b],[m4_require([a])B])
>> m4_defun([c],[a
>> b])
> I still think that c should require both a and b, IOW all zero-argument
> macros should be designed so that they can be required, but that's a way
> more radical change.  Maybe another warning, enabled only with a more
> specific option, would be a good idea.

m4_defun_once provides one level of warning.  Are you suggesting another
approach of changing m4_defun to scan the string?  If there are no
instances of ${n,@,*} in the string, then the macro being defined takes no
parameters, and we can implicitly treat it like a defun_once?  I'm not as
sure about this idea - it is still possible to parameterize no-arg macros
by the current contents of another macro's definition, and since we still
don't allow AC_REQUIRE outside of AC_DEFUN, we still can't enforce that
all zero-argument macros are always required, and never directly expanded.
 Or maybe you are implying one step even further, where AC_REQUIRE becomes
optional, and all zero-argument defun'd macros are implicitly required,
with no effort from the user?  But all of this seems like it should
probably be delayed to post-2.64.

>> is rather common (autoconf, automake, and gnulib all triggered it, and 
>> gnulib 
>> in multiple places), but is also harmless (you can't get out-of-order 
>> expansion 
>> from an ac_require until you have _nested_ ac_require).  So I reworked my 
>> patch 
>> to recognize this case and avoid treating it as a false positive,
> Both patches look like the correct approach; can you add a couple of
> lines to the documentation of the require mechanism in m4sugar.m4?

Thanks for the review.  I've already written NEWS and autoconf.texi patch,
but had not yet done the m4sugar.m4 doc patch.  I'll complete that, post
the updated patch series, and push.  Then the fun begins in rooting out
existing places that trip the warning.

- --
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]