[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: warnings in unit tests

From: Simon Josefsson
Subject: Re: warnings in unit tests
Date: Thu, 10 Jun 2021 10:13:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

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.


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]