On 2013-01-13, Stefano Lattarini <stefano.lattar...@gmail.com> 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