On 01/08/2013 08:15 AM, Stefano Lattarini wrote: > That would be overkill, since AM_PROG_CC_C_O is only required by > projects doing C compilation. Also, IIRC, that macro needs to be > called after AC_PROG_CC, while AM_INIT_AUTOMAKE is typically invoked > before AC_PROG_CC.
But with m4, you can arrange for AM_INIT_AUTOMAKE to redefine AC_PROG_CC so that it hooks in a call to AM_PROG_CC_C_O immediately after its current definition, and thus still preserve desired ordering while making the burden simpler for the configure.ac author. > 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? Is anyone really going to complain if we switch to always supporting inferior compilers? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
