[cmake-developers] CMake API for warnings

[Ruslan Baratov]

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