The behaviour of warning_level=0 does not appear to behave as documented

[apache-hb]

The docs imply, at least in my reading, that warning_level=0 disables all warnings

Set the warning level. From 0 = none to everything = highest

Although after some inspection specifying warning_level=0 leaves the default warning level of the compiler rather than applying /W0, -w, or equivalent. Because of this i've found myself having to patch subprojects quite often due to using a very new compiler with more warnings enabled by default.

Is this intended behaviour?

[eli-schwartz]

warning_level=0 disables meson from adding its own warnings. It doesn't add "disable all compiler warnings", i.e. the -w flag, because frankly that is a terrible horrible idea. It will even disable any manual -Wfoo flags you add by hand.

[apache-hb]

In that case; Is there a recommended way of consuming legacy projects that generate alot of warnings beyond patching the dependencies?

[eli-schwartz]

Which subprojects:

• have bugs which are so bad that the compiler decided it was urgent to warn about them even when no warning flags were passed?
• are generating additional warnings when the compiler is upgraded?

[apache-hb]

I've found that freetype2, as well as zlib produce warnings about macro redefinitions and unknown pragmas. After inspection these warnings were benign, but would still be nice to silence in a cross platform fashion. A more niche usecase is building subprojects as unity builds, which often cause alot of these warnings as many source files define things like WIN32_LEAN_AND_MEAN before including windows.h.

I understand if enabling these sorts of bad habits is a bridge meson wont cross, if that is the case i'd be happy to update the documentation for the warning_level options.

[eli-schwartz]

I've found that freetype2, as well as zlib produce warnings about macro redefinitions and unknown pragmas. After inspection these warnings were benign, but would still be nice to silence in a cross platform fashion.

You originally claimed the issue was upgrading the compiler, producing new warnings.

Are these macro redefinitions and unknown pragmas only showing up after a compiler upgrade e.g. from gcc 12 to gcc 13? I would like to hear more about this.

A more niche usecase is building subprojects as unity builds, which often cause alot of these warnings as many source files define things like WIN32_LEAN_AND_MEAN before including windows.h.

This is a complicated one, because many subprojects do not actually support unity builds at all. You should really ask upstream if they support it, before trying to enable it.

Projects which don't explicitly go out of their way to support unity builds, often demonstrate this by extremely malign redefinitions of global state across Translation Units, that clobber each other and produce invalid code.