[bug-gnulib] m4 & AC_LIBSOURCES (Was: Re: hello at savannah)

[Alexandre Duret-Lutz]

>>> "Jim" == Jim Meyering <address@hidden> writes:
[...]
 Jim> Related to stability and gnulib-tool, just hours ago I raised a
 Jim> point on bug-gnulib about how I think that the relationship
 Jim> between e.g., mempcpy.m4 and mempcpy.[ch] should be encoded
 Jim> via AC_LIBSOURCES, so that automake knows about not just the .c
 Jim> file but also the .h one.  Currently, automake knows about
 Jim> only the .m4->.c dependency, and gnulib-tool has to provide
 Jim> the glue via the Makefile.am section of gnulib/modules/mempcpy:

 Jim> Makefile.am:
 Jim> lib_SOURCES += mempcpy.h

 Jim> I've proposed to add uses of AC_LIBSOURCES and AC_LIBOBJ in many .m4
 Jim> files, where necessary, so that we don't need to depend on gnulib-tool
 Jim> for those additions to lib_SOURCES.  This has been done by autoconf's
 Jim> AC_FUNC_OBSTACK and AC_FUNC_ERROR_AT_LINE for some time.
[...]

That sounds great to me.  IIRC another reason why Akim
introduced AC_LIBSOURCE was to help the creation of a
gnulib-like tool.  This was before gnulib was started and Akim
was considering supplying a pool of replacement .h/.c files with
Autoconf.  Using `autoconf --trace AC_LIBSOURCE' it would be
very easy to compute the set of files to draw for the pool.

To some extent, I've been following the same path with the new
AC_REQUIRE_AUX_FILE macro.  This is supported by CVS Autoconf
and CVS Automake, and also used by CVS Libtool.  (Nowadays
Libtool tells Automake that it needs ltmain.sh, while Automake
had to hardcode this knowledge in the past.)  Maybe this can be
useful to gnulib too, once the next Autoconf and Automake are
released.
-- 
Alexandre Duret-Lutz