bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jim Meyering
Subject: [bug-gnulib] using AC_LIBSOURCES: complementing the `Files:' section
Date: Mon, 06 Dec 2004 12:59:57 +0100

We should be using AC_LIBSOURCES in many of our .m4 files.
I've begun converting some in coreutils.

For example, with the current mempcpy.m4 (which does AC_REPLACE_FUNCS(mempcpy)),
automake is smart enough to add mempcpy.c to the definition of
libfetish_a_SOURCES in coreutils/lib/Makefile.in.

But that still leaves it up to me to manually add mempcpy.h somewhere
in coreutils/lib/Makefile.am.

If instead, I add this line to mempcpy.m4:

  AC_LIBSOURCES([mempcpy.c, mempcpy.h])

or even just this one (IMO the above is better):

  AC_LIBSOURCE([mempcpy.h])

then automake adds mempcpy.h, too.
Note that list of dependent files is already recorded in the
module's `Files:' section, (gnulib/module/mempcpy), but that
doesn't help automake directly.

Note that with modules like save-cwd and chdir-long that don't
already use AC_LIBOBJ there's a little twist.  For those macros,
I have to add both AC_LIBSOURCES and AC_LIBOBJ, e.g.,

  AC_LIBSOURCES([save-cwd.c, save-cwd.h])
  AC_LIBOBJ([save-cwd])

Assuming you agree that using AC_LIBSOURCES is worthwhile,
now we have to resolve the problem of the inherent duplication.

One approach is to require (e.g., via gnulib-tool) that
the .c and .h files listed in the Files: section also be present
in an AC_LIBSOURCES call -- in at least one of the .m4 files listed
in the Files: section.

A more aggressive approach would be to eliminate the .c and .h
file names from the Files: section and to have gnulib-tool extract
them from the .m4 file(s).  IMHO, we can leave that for another day.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]