On 01/13/2013 10:06 PM, Nick Bowler wrote: > On 2013-01-13, Stefano Lattarini <stefano.lattar...@gmail.com> 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
