Cleaning up AC_PROG_CC_C_O semantics (was: Re: [PATCH 2/2] Automatically call AM_PROG_CC_C_O as required.)

[Stefano Lattarini]

[+cc bug-autoconf]

Reference:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#127>

On 01/13/2013 10:06 PM, Nick Bowler wrote:
> On 2013-01-13, Stefano Lattarini <address@hidden> wrote:
>> On 01/13/2013 09:01 PM, Nick Bowler wrote:
>>> +dnl Automatically invoke AM_PROG_CC_C_O as necessary.  Since AC_PROG_CC is
>>> +dnl usually called after AM_INIT_AUTOMAKE, we arrange for the test to be
>>> +dnl done later by AC_CONFIG_COMMANDS_PRE.
>>
>> This would also have the advantage that we shouldn't worry about possible
>> $CC rewrites between the AC_PROG_CC and the AC_OUTPUT invocation.  Your
>> approach might actually be not only the simplest, but also the sanest one.
>>
>> That said, I believe we'd still have to fix AM_PROG_CC_C_O not to rely on
>> the broken AC_PROG_CC_C_O semantics of checking *both* '$CC' and 'cc' for
>> "-c -o" support.  But that is quite orthogonal to your patch, and material
>> for a follow-up anyway.
> 
> Well, that seem more like a something to change in Autoconf, not
> requiring any change in Automake (except maybe we could also fix the
> crazy cache variable naming scheme).  I admit I do not understand the
> rationale for Autoconf testing "plain" cc in addition to the real
> compiler.
>
Me neither.  However, if the autoconf developers agree that the current
AC_PROG_CC_C_O semantic is suboptimal and needlessly complex, and are willing
to change it in Autoconf 2.70, we could simply backport that change in
Automake 1.13.2, and then start relying on the new Autoconf behaviour in
Automake 1.14.

Autoconfers, WDYT?

Thanks,
  Stefano