Hello, On Wed, Sep 21, 2005 at 05:13:24PM +0200, Simon Josefsson wrote: > 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. [...] > Requiring modern tools for gnulib users is probably > ok, but requiring unreleased cvs releases probably is not. ... > 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.
when AC_LIBSOURCE was introduced, we all thought that this problem is not big enough in practice. Later on, when it was realized that a fix is needed, it was decided to wait for Autoconf 2.60, instead of converting gnulib back to the old scheme and later again to the new one. > 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. Having information on one place instead of having it stored redundantly is always good. Script to check that the redundant description are consistent is a kludge. Stepan Kasal _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
