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@ @[EMAIL PROTECTED]/$(DEPDIR)/[EMAIL PROTECTED]@ 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