Re: compilation rules with dependencies don't work with subdir-objects

[Bruno Haible]

Hello Ralf,

Thanks for pointing out this:
> Automake needs to know at 'automake' run time the set of
> dependency files it should later include in the Makefile.in's; those
> | @AMDEP_TRUE@@am__include@ @address@hidden/$(DEPDIR)/address@hidden@
> ...
> The missing 'mkdir -p' for the subdir-objects case is really only the
> simplest missing bit, apart from the needed cleaning additions.

After I added the foo/bar.c file to EXTRA_libgnu_a_SOURCES, all 3 symptoms
are fixed: the dependency includes are in the Makefile.in, all .deps
directories are created when config.status run, and no extra rule for
cleaning the .o, .lo, .libs in the subdirectory are necessary.

I withdraw the claim that it was an automake bug.

> > Huh? The automake documentation, section "Building a library", says:
> > 
> >    Extra objects can be added to a library using the `LIBRARY_LIBADD'
> >    variable.
> 
> Hmm.  This does seem too little qualified indeed.

Actually, that part of the doc is correct. You can add pre-built extra objects
through _LIBADD, or objects compiled from sources - but in the latter case
you need to tell automake that there will be a compilation from
foo/bar.c to foo/bar.o - and the EXTRA_*_SOURCES line does it.

> >     if the option
> >     `subdir-objects' is in effect in the current directory then the
> >     `.o' file will be put into the subdirectory named after the source
> >     file.  For instance, with `subdir-objects' enabled,
> >     `sub/dir/file.c' will be compiled to `sub/dir/file.o'.
> > 
> > So, regardless how you argue, automake should support an object file
> > 'foo/bar.o'.
> 
> It may still be renamed, though.  So this documentation bit is not
> precise either.  Thanks for reporting this.  Your report also reveals
> that the user should be responsible for the rule to create foo/bar.o
> (and to clean it, too).

Yes, this is the crucial point: The user must either define the rule
for building and cleaning foo/bar.o, or give it under automake's
responsibility, through the EXTRA_*_SOURCES variable.

> Automake needs to know at 'automake' run time the set of
> dependency files it should later include in the Makefile.in's; those
> | @AMDEP_TRUE@@am__include@ @address@hidden/$(DEPDIR)/address@hidden@
> 
> lines.  For this it is necessary that automake be able to find out the
> list of objects that the build may need to create.  And this is
> currently done by tracing AC_LIBSOURCE instances.  However, these only
> specify file names (and they currently cannot have a slash in them
> AFAIK), not the LIBOBJDIR that it prefixes.

Fortunately, AC_LIBSOURCES is not the only means of doing so. A normal
EXTRA_*_SOURCES assignment does it as well. And it is for me the preferred
way, because AC_LIBSOURCES is so fundamentally broken, see
  http://lists.gnu.org/archive/html/bug-autoconf/2006-10/msg00002.html
  http://lists.gnu.org/archive/html/bug-gnulib/2005-09/msg00030.html
  http://lists.gnu.org/archive/html/bug-gnulib/2004-12/msg00027.html

Bruno