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

[Stefano Lattarini]

Hi Nick.

On 01/08/2013 03:53 PM, Nick Bowler wrote:
> On 2013-01-08 13:17 +0100, Stefano Lattarini wrote:
>> Actually, the warning about a missing AM_PROG_CC_C_O will be automatically
>> given once the user has added 'subdir-objects' to the AUTOMAKE_OPTIONS.
>>
>>   - the user sees the warning about missing 'subdir-objects' option;
>>   - he adds it to AM_INIT_AUTOMAKE, and calls "autoreconf";
>>   - he now sees the warning about AM_PROG_CC_C_O that is now triggered
>>     by the presence of 'subdir-objects';
>>   - he add AM_PROG_CC_C_O to configure.ac, and calls autoreconf.
>>
>> However, I see that it would be nice to try to be smarter and give
>> the warning right away, to save the user that potentially annoy
>> second bootstrap.  So I still think your suggestion is a good idea.
> 
> I don't think AM_PROG_CC_C_O is optional at all when subdir-objects is
> enabled.
>
I seem to recall differently (in fact, in Automake-NG, 'subdir-objects'
has already been made mandatory, and that didn't require adding
AM_PROG_CC_C_O to all the configure.ac of tests doing compilation of
C files).  To be really sure, though, I'll have to double-check.  If
you are right, we should try to avoid requiring AM_PROG_CC_C_O for
projects that do not actually need it (that is, that don't use per-target
flags and don't have sources in subdirectories, independently of whether
they set the 'subdir-objects' option or not).

> Even with a single source file in a the same directory as the
> Makefile, Automake is generating a suffix rule that looks like this:
>
>   .c.o:
>   [...]
>   @am__fastdepCC_FALSE@       $(COMPILE) -c -o $@ $<
> 
> which looks like it's using -c and -o together to me.
>
This seems indeed wrong.  Can you send a minimal reproducer for this
issue?

> So if subdir-objects is made mandatory, AM_PROG_CC_C_O will become
> mandatory as well, so AM_INIT_AUTOMAKE may as well just call it
> automatically.
>
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.  In addition, AM_PROG_CC_C_O is not required by
projects that don't care about catering to inferior compilers.

In conclusion, even if you are right in the first part of your mail,
the sanest policy is to simply continue to give a warning in the
"portability" category if AM_PROG_CC_C_O is not used in a project
doing C compilation.

Regards,
  Stefano