Re: [bug-gnulib] using AC_LIBSOURCES: complementing the `Files:' section

[Jim Meyering]

Stepan Kasal <address@hidden> wrote:
> On Mon, Dec 06, 2004 at 02:52:05PM +0100, Jim Meyering wrote:
>> Bruno Haible <address@hidden> wrote:
>> > I don't understand the philosophy of registering filenames through
>> > autoconf macros.
>
>> Isn't it more in the spirit of autoconf and automake to use their built-in
>> capabilities to perform this small task rather than to make gnulib-tool
>> do it?
>
> No doubt about this.  I believe Bruno meant that autoconf should deal
> with things which has to be determined at the build time.  Automake,
> OTOH, does things which are done at the moment when the distribution
> tarball is built.

But automake already handles this in part: it knows the semantics of
AC_LIBOBJ and AC_REPLACE_FUNCS, and adds .c files to the source list
when it can determine it is appropriate.  By adding strategic uses of
AC_LIBSOURCES, we are letting automake do the whole job (of adding both .c
and .h files) rather than just the minimal amount (typically the .c file).

> That means that you need AC_LIBOBJ to modify the LIBOBJ list on the
> autoconf side.  But the list of the source files which have to be
> distributed is maintained in Makefile.am.
>
> Thus the module should add
>
>       lib_SOURCES += mempcpy.h memcpy.c

No.  That would induce an error from automake about your manually
including a .c file (mempcpy.c) that it has already included automatically
(thanks to its interpretation of AC_LIBOBJ or AC_REPLACE_FUNCS calls).

> to lib/Makefile.am and some autoconf code to call AC_LIBOBJ if
> necessary.  (I don't understand why this line doesn't contain memcpy.c
> at the moment.)

Thank you.  You have just provided another reason for making the
current process a little cleaner: it will be more understandable.

>> Then even packages (ahem :-) that don't use gnulib-tool can
>> benefit from that dependency information.
>
> The module description contains configure.ac fragments and Makefile.am
> fragments.  gnulib-tool collects (should collect) both.
>
>> Besides, if I write an autoconf macro to detect and potentially
>> replace a function, I consider the replacement .c file (and of course
>> its header file) to be tightly enough coupled to the macro that it is
>> only logical to include their names in the definition of that macro.
>
> Well, you have to place the file to the lib subdir (manually or via
> gnulib-tool), so it's natural that you have to add it to the source
> list in lib/Makefile.am (again, either manually or via gnulib-tool).

One of my points was that not everyone uses gnulib-tool,
and others shouldn't have to do it manually.

> I tend to agree with Bruno that we should go this way and we shouldn't
> use AC_LIBSOURCE.

Have a nice day,

Jim