[cmake-developers] CMake API for warnings

[Brad King]

On 04/13/2016 01:20 AM, Ruslan Baratov wrote:
>>> new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may control this.
>> I'd prefer to avoid extra knobs if possible.
> Okay, what about CMake warning for developer? (cmake -Wdev/cmake -Wno-dev)

Sure.

>>> You mean this:
>>>
>>>       compatibility-c++98=off
>>>       inline=off
>>>       special-members=off
>>>       catch-semantic-changed=off
>>>       covered-switch-default=off
>>>       inherits-via-dominance=off
>>>       name-length-exceeded=off
>>>       padded=off
>>>       this-used-in-init=off
>>>       EVERYTHING=on
>>>       EVERYTHING=error
>>>
>>> versus this one:
>>>
>>>       DISABLE
>>>         compatibility-c++98
>>>         inline
>>>         special-members
>>>         catch-semantic-changed
>>>         covered-switch-default
>>>         inherits-via-dominance
>>>         name-length-exceeded
>>>         padded
>>>         this-used-in-init
>>>       ENABLE
>>>         EVERYTHING
>>>       TREAT_AS_ERROR
>>>         EVERYTHING
[snip]
> All I'm trying to say about ENABLE/DISABLE lists is that if user will 
> have N warnings to enable and M warnings to disable he will not write N 
> times *=on and M times *=off and probably will just create helper functions:

I realized there is a difference between the low-level plumbing representation
of this in the property values and the porcelain provided by a new command
like target_compile_warnings.  I've been thinking of the plumbing and you've
been thinking of the porcelain.  They do not have to be the same.  The
plumbing could even use 0/1 instead of off/on to work better with a genex.

We need to work out designs for both such that they can work together and
the command can easily map to the internal property representation.  Perhaps
having separate properties for _ENABLE, _DISABLE, and _ERROR is the way to
go, perhaps not.  Either way we can diagnose inconsistent value combinations.

> so how about this:
> 
>     compile_warnings(DISABLE foo CONFIGURATION Debug)
>     compile_warnings(ERROR foo CONFIGURATION NOT Debug)

I'd prefer to use generator expressions for the per-config values instead
of an explicit CONFIGURATION porcelain, at least at first.

> I'm pretty sure all compilers have flag to enable all kind of available 
> warnings (it may not call "All", e.g. -Weverything for Clang). Even if 
> there is such compiler we can use maximum level + adding extra warnings 
> explicitly. There must be abstracted group that allow to enable 
> everything.

Okay.  We can document the "everything" mode as meaning CMake will do
a best-effort to add all warnings the compiler can provide, at least
without resorting to adding lots of individual flags.

Thanks,
-Brad