On 2026-03-02 02:16, Simon Josefsson wrote:
I've not felt a need to ignore those, and the design philosophy of manywarnings is to enable ALL possible warnings and then allow maintainer to back out of things that they disagree with.
Yes, that's the basic idea, though we do omit some warnings where we think they're invariably counterproductive in Gnulib-using code, e.g., -Waggregate-return, -Walloc-zero, -Walloca (see build-aux/gcc-warning.spec for more). Many omitted warnings are no-brainers, whereas some (e.g., -Wcast-qual) are debatable.
Given that basic idea, when in doubt it's better to not omit debatable warnings, so that the maintainer can back out unwanted warnings. Perhaps we should even rethink -Wcast-qual and a few others, though any change there might be painful.
Of the warnings Bruno listed, -Wgnu-include-next seems a no-brainer given that Gnulib uses include_next so often. The others look like they might be more-debatable style issues, though I'm by no means expert in running across them.
We could provide some pre-defined set of warnings to ignore, for maintainers who wish to opt-in and ignore entire sets of warnings, perhaps?
Yes, we could support something finer-grained than just the "list all possibly-useful warnings" set that we do now. But then we'd have to maintain yet another set (or sets) of warnings, and figure out what the inclusion criteria are.
