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

[Ralf Wildenhues]

Hello Bruno,

Thanks for your feedback.  It cleared some points up for me.

* Bruno Haible wrote on Wed, Nov 08, 2006 at 06:40:08PM CET:
> 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.

Hmm.  This does seem too little qualified indeed.

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

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

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

Yes.  But: 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.
        
Also please note that the dependency tracking is already broken without
any subdir objects at all: since you overwrite AC_LIBOBJ or not use it
at all, not all .deps/*.Po files that need to be included from the
Makefile really are included.  So your current dependency tracking does
not work reliably, because gl_LIBOBJ does not touch all the hooks that
automake exploited with AC_LIBOBJ.[1]

The missing 'mkdir -p' for the subdir-objects case is really only the
simplest missing bit, apart from the needed cleaning additions.

FWIW, I really haven't understood what the subdir-objects case is useful
for in this context: gllib currently has a flat directory structure.
Is it just for convenience or is there a necessity behind it?

And please don't get me wrong: I would love to solve all this mess,
I don't personally care much whether in Gnulib or in Automake (for
generality and reusability it would probably be better in the latter),
but really so far the gnulib thread titled 'gnulib taking over libobjs?'
has scared me too much to read it in detail.  And whether contrary to
some design philosophy or not, I think there was simply no different way
seen to realize dependency tracking for LIBOBJS in Automake.

Cheers,
Ralf

[1] Try this:
gnulib-tool --test acl  # interrupt after autoreconf
cd ...                  # change into the source tree directory
grep include gllib/Makefile.in  # does not list acl.Po and some others