bug#13378: [IMPORTANT] Make the 'subdir-objects' setup the default, and only available one

[Stefano Lattarini]

On 01/08/2013 04:29 PM, Eric Blake wrote:
> 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.
>
This is true, but I'd have preferred to avoid this shenanigans with
macro redefinitions if at all possible.  It seems it won't be really
possible though (see also my reply to the last message from Nick):
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#47>
:-(

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

So I think your proposal is the way to go, *right for Automake 1.13.2*,
since it offers a bug fix for the situation described in
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13378#47>

AM_PROG_CC_C_O should be kept as a no-op for the moment, but deprecated
*in documentation only* as no longer useful, and then, maybe, starting
from Automake 1.14, deprecated also by non-fatal runtime warnings.

Further suggestions, examples or patches would be very welcome (just
ping me if you plan to attempt a patch, to avoid unwitting duplication
of efforts).

Thanks,
  Stefano