Re: Feature request: -Wno-unknown-warnings to silently ignore unknown warning control flags.

[Eric Gallager <egall at gwmail dot gwu dot edu>]

On Thu, Oct 12, 2017 at 4:46 AM, Oren Ben-Kiki <gcc-oren@ben-kiki.org> wrote:
> Motivation/Use case:
>
> * Since gcc/g++ intentionally does not have `-Weverything`, there is a
> number of explicit `-W...` flags one might wish to specify explicitly. Fair
> enough.
>
> * Additional `-W...` flags are introduced in new gcc/g++ versions, which
> check for new potential code smells, possibly related to later language
> standards. That's great (thanks!).
>
> * Not all platforms run the latest gcc/g++ compiler version. So build tools
> need to deal with a range of versions.
>
> Taking these three points together, we have a problem. The build tool
> wishes to specify `-Wshiny-new-warning` but may only do so if the gcc/g++
> compiler version is above some version X.
>
> This is difficult for several reasons:
>
> * The documentation does not clearly specify the 1st compiler version that
> supports each error/warning command line flag. One has to manually
> backtrack through the release notes for all the compiler versions.
>
> In fact the documentation also doesn't make it easy to see which flags are
> covered by other flags - one has to read through the documentation, one
> flag at a time, and extract the information from the English text. Some
> form of a more structured table would have been awesome: 1st compiler
> version supporting the flag, the list of other flags such as `-Wall` that
> imply the flag, maybe a list of related flags such as `-f...`. But that
> aside...
>
> * Even if we know which compiler version to check for, this quickly becomes
> a PITA to maintain in the build tool, given the large number of compiler
> versions in use in the wild. Having many versions means the compiler has
> been actively progressing at a fast rate, which is great! But it makes it
> nasty to deal with providing the correct warning flags for the correct
> compiler version.
>
> This is (mostly) solved with the new proposed flag: the build tool would
> simply list all the desired warning flags, which would be silently ignored
> by older compiler versions.
>
> Typos are a potential issue. One would have to run a "recent" version
> without the `-Wno-unknown-warnings` to catch such typos; that would be
> rare, and is simple enough to do (and automate in the build tool if
> desired).
>
> Another obvious issue is that the new `-Wno-unknown-warnings` flag would
> only be available starting in a future compiler version. So build tools
> would have to deal with the problem for a long time before the flag would
> provide its full benefits. Barring having a working time machine ;-)
>
> However, it is much simpler for a build tool to do a single test of whether
> or not the compiler version supports the proposed new flag, than to deal
> with the full problem of multiple versions. If the new flag is not
> supported, the build tool could fall back to using a conservative set of
> warning flags.
>
> Also, as time goes by, older compiler versions would eventually be phased
> out, so even this test would be (eventually) removed. Sure, it would take a
> decade or more, but: as the saying goes, "The best time to plant a tree is
> 20 years ago; the second best time is today".
>
> Thanks,
>
> Oren Ben-Kiki

If you use autoconf to generate a configure script for your project, I
recommend using the macros from gnulib's manywarnings.m4 and related
files:

https://www.gnu.org/software/gnulib/manual/html_node/warnings.html#warnings
https://www.gnu.org/software/gnulib/manual/html_node/manywarnings.html#manywarnings