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

[Stepan Kasal]

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