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

[Nick Bowler]

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.

> 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.

Cheers,
  Nick