On Thu, Oct 12, 2017 at 4:46 AM, Oren Ben-Kiki <gcc-o...@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
