Bruno Haible <br...@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
signature.asc
Description: PGP signature
