[cmake-developers] CMake API for warnings

[Ruslan Baratov]

Sounds good?

On 06-Apr-16 01:03, Ruslan Baratov via cmake-developers wrote:
> On 05-Apr-16 21:03, Brad King wrote:
>> On 03/31/2016 12:47 PM, Ruslan Baratov wrote:
>>> What about 3 properties containing list of <warning-id>'s (groups
>>> unexpanded):
>>>
>>> * COMPILE_WARNINGS_DISABLE # e.g. "shift-sign-overflow;unused"
>>> * COMPILE_WARNINGS_ENABLE # e.g. "ALL"
>>> * COMPILE_WARNINGS_TREAT_AS_ERROR # e.g. group + specific: 
>>> "inline;undef"
>> We would need to define behavior when a warning appears in more than
>> one list.
>
> Report an error in case of any type of conflicts. It may happens not 
> only when same type appears in both DISABLE and ENABLE but for example 
> when warning already defined by some group. E.g. "EVERYTHING;undef" is 
> the same as "EVERYTHING". If user okay with having intersections (for 
> any reason) new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may 
> control this.
>
>>    Perhaps we need to define some kind of `=on/off/error/no-error`
>> syntax for each list entry.
>
> 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
>
> ?
>
> Second variant looks clearer for me.
>
>>
>> The name "ALL" may not be representative.  Even -Wall does not really 
>> enable
>> all possible warnings on some compilers.  I'd like to find another 
>> name that
>> captures the idea of enabling most warnings.  Or we could try to 
>> subsume it
>> into an interface for the warning level, with -Wall considered "high".
>
> Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET?
>
>>
>>> I'm not sure about mixing more languages. I think it will be similar to
>>> COMPILE_OPTIONS (?), see no language specification in
>>> `add_compile_options` command.
>> Right.  We do have the COMPILE_LANGUAGE genex for some limited use 
>> cases.
>> Its documentation even includes a COMPILE_OPTIONS example. However, it
>> also documents that it is not possible to implement fully on VS IDE
>> generators.  For example, VS does not distinguish between C and C++
>> flags.  The same set is always used for both.
>
> Since /Wall can be set by 'target_compile_options' then abstracting it 
> by `target_compile_warnings(... ENABLE ALL)` should not be a problem I 
> think.
>
>>
>> Another option is to have the warning names themselves have a language
>> in them, similar to the COMPILE_FEATURES names.
>
> See no point of this one. So say we have switch-enum warning which is 
> only for C++, why do we need cxx-switch-enum? There is no 
> c-switch-enum or any other *-switch-enum. If we are talking about 
> 'undef' why do we need c-undef and cxx-undef? It mean the same and I 
> think will be set or unset simultaneously.
>
> Ruslo