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

[Bruno Haible]

Ralf Wildenhues wrote:
> This is currently simply not supported by Automake.

Huh? The automake documentation, section "Building a library", says:

   Extra objects can be added to a library using the `LIBRARY_LIBADD'
   variable.

> Object file names are an internal detail of Automake

I understand that when my Makefile.am mentions only the source files
explicitly, automake has the freedom to choose the object file names.
But here I specified the object file names.

Besides that, even if automake would insist in re-computing the file names
that I already specified, I put 'subdir-objects' into Makefile.am, which
according to the doc has this effect:

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

> and there is special hackery going 
> on to support AC_LIBOBJ, as you very well know.  As far as Automake is
> concerned, you're violating this as soon as you don't use
> AC_LIBOBJ/$(LIBOBJS)/$(LTLIBOBJS) or $(ALLOCA).

The automake doc does not state that using AC_LIBOBJ is mandatory. In fact,
such a requirement would be contrary to automake's design philosophy.
automake's design philosophy is that it provides rules for some common cases
and leaves the user the freedom to the developer to create normal Makefile
rules for his special needs.

I'm not using this AC_LIBOBJ at all, because its design and implementation
does not fit with gnulib's requirements. You know that very well.

> I wonder whether it's useful to try to fix the setup you reported in
> Automake

If you don't fix it in automake, gnulib-tool will have to use 'no-dependencies'
(at least in some situations), and half of the gnulib users will be unhappy
about that.

> or to give another try at resurrecting support for multiple 
> AC_CONFIG_LIBOBJ_DIRs in some way or other.

There is no need for such a feature from gnulib's side.

Let me summarize the bug again:
  - I add some object files to libgnu_a_LIBADD and libgnu_a_DEPENDENCIES,
    which is a valid thing to do and an essential feature.
  - Automake adds a generic rule for compiling .c to .o files, that is
    different from the default generic rule known to 'make'.
  - An 'mkdir -p' is missing somewhere in this default rule or in the
    depcomp script.

Bruno