[cmake-developers] CMake API for warnings

[Ruslan Baratov]

On 29-Mar-16 21:24, Brad King wrote:
> On 03/29/2016 09:09 AM, Ruslan Baratov wrote:
>> As a general note obviously I've used another approach because I decide
>> to create CMake module which can be used with regular CMake versions :)
>> Of course implementing this in CMake "from the box" is best.
>>
>> Are we talking about levels only or about control of exact kind of
>> warnings too (like `-Wswitch`/`-wswitch`/`-Werror=switch`)?
> At a minimum we should support levels (e.g. all, default, none) that
> are generic enough to have mappings to flags on every compiler.  Later
> one could consider more granular switches with enumerated options that
> may not all have flags on every compiler.

> OTOH many such switches are
> so specific that they should not be abstracted and can instead be
> added to COMPILE_OPTIONS with a $<C_COMPILER_ID:...> genex guard.
What about generating nothing for such cases? E.g. code:

   try {
   }
   catch (...) {
   }

produce "catch-semantic-changed" warning on MSVC but it's okay for 
Clang. So we can add `/w4571` for MSVC and nothing for other compilers.

>
> I think these warning properties should perhaps be done as usage
> requirements with propagation through INTERFACE_* properties.  I'd
> need to see some example use cases spelled out though.
But not if target is installed. It will be quite inconvenient if 3rd 
party package add some flags to local targets. Is it possible to support 
it from the box? Requirements are handy when we are talking about 
different code generated with different compile flags. Warnings have 
different nature. Fact that we are using `-Wall` or not using `-Wall` 
doesn't change final binary or affect compatibility.

>
> Once such directory/target properties are available then we could look
> at making them take over the role of providing default warning flags
> instead of putting them in the CMAKE_<LANG>_FLAGS* variables.  That may
> need a policy as you pointed out earlier.
>
> -Brad
Great.


What about this:

     compile_warnings # modify directory properties
     target_compile_warnings # modify target properties
     sources_compile_warnings # modify source properties

Same API for all:

    *_compile_warnings(<global/target/source> DISABLE <warning-id> 
ENABLE <warning-id> TREAT_AS_ERROR <warning-id>) # may be plus 'APPEND' 
for extending instead of overwriting (?)

General warning-id's:

   * ALL
   * DEFAULT
   * LEVEL<N>

Group warnings-id's:

   * inline # MSVC: 4711 (automatic-inline), 4714 (force-not-inlined), 
4710 (not-inlined), 4514 (unreferenced-inline)
   * compatibility-c++98 # Clang: `-Wc++98-compat`, 
`-Wc++98-compat-pedantic`

Simple warning-id examples:

   * undef  # Clang/GCC: `-Wunder`; MSVC: 4668
   * shift-sign-overflow # Clang: `-Wshift-sign-overflow`, GCC: nothing, 
MSVC: nothing
   * inherits-via-dominance # Clang/GCC: nothing, MSVC: 4250

Ruslo