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

[Nick Bowler]

On 2013-01-08 16:15 +0100, Stefano Lattarini wrote:
> On 01/08/2013 03:53 PM, Nick Bowler wrote:
[...]
> > 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).

That would be fine, but I wonder if the code to "optimize" subdir-objects
would actually be any simpler than just keeping subdir-objects as an
option...

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

Well, the rule itself does not look wrong.  The -o $@ is required for
this suffix rule to work properly with subdir-objects -- otherwise, the
suffix rule would have the compiler place its output in the working
directory which is even more wrong.

But anyway, here's the test case I used (I've not had a chance to
install 1.13 yet, so I only tested it on 1.11.6 and 1.12.6):

  % cat >configure.ac <<'EOF'
AC_INIT([test], [0])
AM_INIT_AUTOMAKE([foreign subdir-objects])
AC_PROG_CC
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF

  % cat >Makefile.am <<'EOF'
bin_PROGRAMS = foo
EOF

  % cat >foo.c <<'EOF'
int main(void) { return 0; }
EOF

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

These are very good points that I had not considered.  But I don't
think they are unsurmountable.  It should be straightforward to have
AM_INIT_AUTOMAKE arrange (using AC_CONFIG_COMMANDS_PRE) for
AM_PROG_CC_C_O to be called later, and only if it's appropriate to
do so.  I can probably cook up an example later.

> In addition, AM_PROG_CC_C_O is not required by projects that don't
> care about catering to inferior compilers.

Since the AC_PROG_CC_C_O test is so trivial, I don't think Automake
should should care about catering to projects that don't care about
catering to inferior compilers.  If such projects really, really want to
avoid the test, they can do m4_define([AM_PROG_CC_C_O]).

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

Hm, I think the sanest policy is for Automake to automatically do the
right thing when it is possible to do so.

Chers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)