Re: regex-0.12's regex.h seems to have a little bug

[Simon Josefsson]

Stepan Kasal <address@hidden> 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