Bruno Haible <bruno@clisp.org> writes:

> The other reason is that every package maintainer has their preferred set of
> warnings — that's what the 'manywarnings' module is made for —, but it does
> not make sense for package maintainers to enforce the absence of certain
> warnings on code that 1) they don't maintain, 2) does not end up in the
> binaries produced (installed) by their package.

I agree with that.  The unfortunate result, however, is that maintainers
are less likely to enable gnulib self-tests in their packages, since it
creates additional work.

I try to have gnulib tests enabled, but sometimes I disable them because
having them enabled leads to problems that are too time-consuming to
debug and fix.  Most of my projects have multiple gnulib instances in
them, which gnulib self-tests does not support.

I've seen over the years a number of cases where old releases of my
packages fail to 'make check' correctly only because of a gnulib
self-test that was 1) simply buggy, or 2) the gnulib replacement code
had bugs in them on some platform, or 3) the self-test tested a
corner-case that newer platforms (for valid reasons) chose to behave
differently for.

I think there is room for improvements in this field, with the goal of
making it easier for maintainers to always include all gnulib
self-tests, but I don't really know what it could be.

/Simon