Subject: bug#13378: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required.

From: Stefano Lattarini <[email-masked]>
Date: Mon, 14 Jan 2013 11:23:00 +0100

On 01/13/2013 10:06 PM, Nick Bowler wrote:
> On 2013-01-13, Stefano Lattarini <[email-masked]> wrote:
>
>> Another useful follow-up would be to move the AM_PROG_CC_C_O in a private
>> macro (to be expanded in AC_CONFIG_COMMANDS_PRE like you did above), and
>> make AM_PROG_CC_C_O a no-op (without runtime deprecation).  That way, we
>> could rely on the improved semantic of having the potential '$CC' rewrite
>> placed near the end of configure, rather than near the beginning.  WDYT?
> 
> With AC_CONFIG_COMMANDS_PRE, AM_PROG_CC_C_O would still be required if
> package authors want to make use of the "compile" wrapper in configure
> tests -- essentially, configure.ac can call AM_PROG_CC_C_O to force the
> test to happen where it is needed, rather than just before AC_OUTPUT.
> 
> I think it'd be worthwhile to keep that working.
>
Ah, but the $CC rewrite has always been an undocumented hack, and relying
on it is a bad idea.  Still, your reasoning makes it clear that changing
that semantics abruptly might cause subtle backward-incompatibilities in
corner-case but perfectly valid situations.  Hmmm...  I think it's better
to follow your approach for now, and then, if and when we decide to fix
our macros not to rewrite $CC, do so with proper NEWS and documentation
warnings beforehand, and a viable deprecation plan.

Thanks,
  Stefano