[Top][All Lists]

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

[sr #110350] AX_PROG_CC_FOR_BUILD broken with 2.69c

From: Benjamin Moody
Subject: [sr #110350] AX_PROG_CC_FOR_BUILD broken with 2.69c
Date: Tue, 17 Nov 2020 19:59:06 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0

Follow-up Comment #3, sr #110350 (project autoconf):

I think I understand.  Trying to define a test case feels a bit like you're
trying to formalize what was a somewhat kludgy workaround to begin with.

Given the way AX_PROG_CC_FOR_BUILD currently works, it's hard to see any way
of supporting it that doesn't rely (implicitly or explicitly) on whether CC is
defined as a macro.

On the other hand, AX_PROG_CC_FOR_BUILD _also_ relies on setting shell
variables before/after running the checks, so it requires that the checks be
performed at the location where AC_PROG_CC appears in the code.

So one option would be to define the body of AC_PROG_CC as a shell function,
where the name of the function is [ac_fn_prog_]CC or something like that - so
with AX_PROG_CC_FOR_BUILD you end up with ac_fn_prog_CC() that sets $CC and
$CFLAGS, and ac_fn_prog_CC_FOR_BUILD() that sets $CC_FOR_BUILD and
$CFLAGS_FOR_BUILD.  The result would be similar to Autoconf 2.69 in
performance - multiple instances of AC_PROG_CC would call ac_fn_prog_CC()
multiple times, but the result would be cached.  But this would still serve
the goal of reducing the size of configure.

Another option would be to make the workaround explicit, saying that _if_ CC
is defined as a macro, then we run the checks at the location where AC_PROG_CC
appears (perhaps through a shell function, perhaps not), and if CC is _not_
defined then we merely require the checks to be performed prior to the current

With an explicit "ifdef" it's also possible to show a warning that this usage
is deprecated.


Reply to this item at:


  Message sent via Savannah

reply via email to

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