[Top][All Lists]

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

Re: autoconf 2.64 warning: AC_REQUIRE: `AC_PROG_CC' was expanded before

From: Eric Blake
Subject: Re: autoconf 2.64 warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was required
Date: Sat, 16 Jan 2010 06:38:17 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Thunderbird/ Mnenhy/

According to Carsten Heinrici on 1/16/2010 5:45 AM:
>> This scenario is described in the manual:
> yes, I read this ... and tried to understand, but it is not too easy.
>> Without seeing your, I can't tell you the exact fix, but it
>> is likely to be a matter of using AC_REQUIRE in more places, or perhaps an
>>  AC_DEFUN_ONCE instead of AC_DEFUN of your macro that is wrapping the call
>> to AC_PROG_CC.
> As far as I understood, it is caused by a direct expansion of
> AC_PROG_CC within another macro FOO defined using AC_DEFUN, instead of
> either
> a) using AC_REQUIRE, or
> b) m4_define(FOO). or
> c) expanding AC_PROG_CC in the body of
> The main problem is, that we want to support more compilers, named
> differrently from the default list 'gcc cc' used by AC_PROG_CC.

It's more than that - it is caused by direct expansion of AC_PROG_CC
within another macro FOO, where FOO then calls macro BAR, and macro BAR
uses AC_REQUIRE([AC_PROG_CC]).  For discussion sake (since you haven't
posted your original macros), I'm assuming you have:
AC_PROG_CC([armcc tcc cl c51 and so on])

> Unfortunately, none of the options are satisfying:
> a) does not support passing parameters to AC_PROG_CC

AC_REQUIRE can pass arguments, it is just that the arguments are only
honored by the first caller to AC_REQUIRE (and the documentation for
calling AC_REQUIRE with arguments is sparse).  That is, I think it can be
as simple as patching foo.m4 as follows:

+AC_REQUIRE([AC_PROG_CC], [AC_PROG_CC([armcc tcc cl
+   c51 and so on])])

> b) will not be supported by aclocal which requires AC_DEFUN and the
> macro FOO is defined in another file

Exactly, which is why I listed option C in the manual.

> c) would require to change all, and there are many of them

No, that still only requires a change to foo.m4:

-AC_PROG_CC([armcc tcc cl c51 and so on])
+AC_PROG_CC([armcc tcc cl c51 and so on])

> The manual describes another solution, by changing the required macro,
> but this would mean to change AC_PROG_CC.

Correct - you can't change AC_PROG_CC (well, you can, by patching
autoconf, but then everyone else running unpatched autoconf can't build
your package; or you could redefine AC_PROG_CC, but that gets hairy to
maintain).  But you CAN change FOO, since it was FOO that had the problem
in the first place.

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

Eric Blake             address@hidden

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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