Stepan Kasal <[EMAIL PROTECTED]> writes: > Hi, > I don't say I'm excited about the AC_LIBSOURCE macro, ...
To understand what I'm writing below: I think AC_LIBSOURCE probably is the right solution, but it would have been nice to introduce it after the autoconf/automake/libtool/m4 releases had happened. Then we would have avoided the conflict with existing use of AC_LIBOBJ and AC_REPLACE_FUNCS. Requiring modern tools for gnulib users is probably ok, but requiring unreleased cvs releases probably is not. > 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. Right. > 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. Module maintainers always has to do the right thing. This potential mistake is possible to detect through a script, so if this was a genuine problem in the old scheme, we could write that script. > - 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. This doesn't seem like a huge improvement. > 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. Problem is, the new scheme causes real problems if you used AC_LIBOBJ or AC_REPLACE_FUNCS before, and put the LTLIBOBJ in another directory than the gnulib files. Regards, Simon _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib