Re: warnings expanding macros before they're required

[Eric Blake]

On 07/11/2011 02:27 PM, Mike Frysinger wrote:
> On Monday, July 11, 2011 15:50:42 Eric Blake wrote:
>> On 07/11/2011 01:31 PM, Mike Frysinger wrote:
>>> with this little bit of code:
>>> $ cat common.m4
>>> AC_DEFUN([SIM_AC_COMMON],[
>>> AC_PROG_CC
>>
>> Change this to AC_REQUIRE([AC_PROG_CC]), and that should also avoid the
>> warning.
> 
> seems to work, but only if i quote [].  using AC_REQUIRE(AC_PROG_CC) ends up 
> spitting a lot of stuff to stderr which seems bad ...

Well, yeah.  AC_REQUIRE _requires_ that its argument be quoted (you are
requiring that the macro named [AC_PROG_CC] has been previously
expanded, and not that the macro named (big long pile of AC_PROG_CC
expansion) has been previously expanded.

> 
>> I suggest using proper m4 quoting:
> 
> the code mostly is quoted properly ... this example was hand written for 
> showing the issue

Hand-written examples do best when using the same proper quoting as the
file they are copying from.

>>
>> 2.64 doesn't produce the warnings; but silently produced a broken
>> configure instead.
> 
> the warning output i posted was from using autoconf-2.64.  that's how i 
> noticed originally, but then made sure to try the latest version before 
> reporting a bug.  i guess you mean "<2.64" and not "<=2.64".

/me goes and rereads NEWS...
Oh, you're right.  It's listed as the second news item under 2.63b.

> 
>> 2.68 outputs a fixed configure, at the expense of
>> outputting the code for AC_PROG_CC twice; the warning exists to tell you
>> that you can shrink the size of your configure by fixing things to avoid
>> the warning.
> 
> thanks ... the warning displayed didnt convey that's what was actually 
> happening.  perhaps it should be updated with the URL you provided here.

At the time the code was written to produce the warning, the FAQ URL
didn't exist.  I'm not sure if a patch would help now, as most projects
have already had time to adjust, but it may be worth considering one if
a patch is provided.

> 
>> In Autoconf 2.68, you end up with this layout:
>>
>> # prereqs to SIM_AC_COMMON
>> # body of AC_PROG_CC - $CC is set before use
>> # prereqs to AC_CHECK_HEADERS, including code that uses $CC
>> # body of SIM_AC_COMMON
>> # body of AC_PROG_CC - redundant, hence the warning
>> # body of AC_CHECK_HEADERS
> 
> seems like autoconf should be smart enough to not do this

It was already hard enough to coax m4 into displaying the warning when
it output redundant code without exploding the execution time of
autoconf.  I don't think it is possible to make autoconf any smarter
than what it already is on this front - the best we can do is output a
warning and rely on you to fix your configure.ac file to use AC_REQUIRE
instead of direct expansion to avoid the redundancy in the first place.

After all, the difference between:

AC_REQUIRE([AC_PROG_CC]) # Guarantee that AC_PROG_CC has been expanded
at least once before now

and:

AC_PROG_CC # Expand AC_PROG_CC now, even if it has already been expanded
in the past

is intentional and documented, and there are some macros where you
_want_ them to be expanded twice, even if AC_PROG_CC doesn't happen to
be one of those macros.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature