On 01/08/2013 10:11 PM, Peter Rosin wrote: > On 2013-01-08 20:27, Stefano Lattarini wrote: >> On 01/08/2013 04:29 PM, Eric Blake wrote: >>> On 01/08/2013 08:15 AM, Stefano Lattarini wrote: >>>> In addition, AM_PROG_CC_C_O is not required by >>>> projects that don't care about catering to inferior compilers. >>> >>> How much speed penalty and configure bloat are we talking about by >>> allowing projects to omit the use of this macro if they don't care about >>> inferior compilers? >>> >> Almost zero bloat. The code simply re-uses a cache variable set by >> AC_PROG_CC, and, *for losing compilers only*, plays some dirty but >> inexpensive tricks with $CC redefinition. > > Not quite, the cache variable is from AC_PROG_CC_C_O which is is not > invoked by AC_PROG_CC, at least I don't think so? AM_PROG_CC_C_O > requires AC_PROG_CC_C_O so it costs a couple of extra compile tests. > Ouch. Thanks for correcting me on this.
> Not that I'm complaining if those tests are always performed though, > just trying to keep the arguments honest... > Alas, I wasn't being dishonest here, just dumb/distracted ;-) > (but again, I haven't actually checked if AC_PROG_CC triggers > AC_PROG_CC_C_O) > Nope. Maybe it could do so in future Autoconf version though? This would be a good occasion to fix some weird AC_PROG_CC_C_O behaviours (e.g., the fact that it's checking both "cc" and "$CC"). Eric, WDYT? Regards, Stefano
