Hi, I don't say I'm excited about the AC_LIBSOURCE macro, ... On Wed, Sep 21, 2005 at 11:02:24AM +0200, Simon Josefsson wrote: > I'm not sure what the supposed advantage with > AC_LIBSOURCES was compared to the old scheme.
... but I think I do remember what was the advantage: Imagine that a new file baz.c is added to a module. Then it is possible that you upgrade the existing files, including the m4 file which checks whether baz.c is needed, but that you forget to copy the new file, or you forget to add it to the list of distributed files. With the old scheme, the bug would be detected only on platforms where baz.c is needed. Typically, the developper uses a variant of GNU system, so most of the replacements are not needed; so the bug is not detected on his platform. With the AC_LIBSOURCES, Automake uses traces to obtain the list of distributed files, so we are sure that baz.c will be distributed. (And if it wasn't copied into the project, Automake will complain on every platform, no matter whether the file would be actually built there.) Yes, you might object that the mistake described above will not happen when people use gnulib-tool. But: - with the old scheme, the module maintainer had to add the file to the module description, _twice_: to the file list and to the lib_SOURCES variable in Makefile.am section. - with the new scheme you only add something like if test "$baz_works" != yes; then AC_LIBOBJ([baz]) fi and it expands to AC_LIBSOURCE([baz.c]) which is traced by Automake. Please note that almost always you need to add a check for the feature anyway, so the code required by the new scheme presents almost no overhead, and, more importantly, the risk that you forget to add it is minimal. So that's it. Stepan Kasal _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib