[cmake-developers] CMake API for warnings

[Ruslan Baratov]

On 13-Apr-16 01:00, Brad King wrote:
> Hi Ruslo,
>
> Sorry for taking so long to respond here.  I've been hoping to find time
> to think through the design deeply but I don't know when that may happen.
> Here is some more feedback.  I invite others to jump in here.  Without
> more interest I'm hesitant to proceed.
>
> On 04/05/2016 02:03 PM, Ruslan Baratov wrote:
>> Report an error in case of any type of conflicts.
> Yes.
>
>> 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)

>
>> 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
> Consider examples where we don't have the full list ahead of time and
> are instead appending.
-

>    Or, what if we want to check the current property
> value to see if some setting is already present?
What do you mean?

>    Compilers use flags like
>
>    -Wxyz -Wno-abc -Whjk=error
>
> and not
>
>    -WDISABLE $w1 $w2 -WENABLE $w3 $w4
I don't think the reason of approach used in compilers is about been 
convenient for user to analyze command line flags. CMake can do much 
better job here.
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:

function(enable_warnings_list ...)
   foreach(warning ...)
     list(APPEND result ${warning}=on)
   endforeach()
endif()

So instead of writing extra different modules by a lot of developers why 
not support this from the box?

>
> so IMO the individual values are easier to reason about.  Also one could
> imagine having the value come from a generator expression, e.g.
>
>     foo=$<CONFIG:Debug>
As far as I understand we should allow on/off/error, so effectively it 
will be:

foo=$<$<CONFIG:Debug>:off>$<$<NOT:$<CONFIG:Debug>>:error>

so how about this:

    compile_warnings(DISABLE foo CONFIGURATION Debug)
    compile_warnings(ERROR foo CONFIGURATION NOT Debug)

?

>
>>> I'd like to find another name that captures the idea of enabling most warnings.
>> Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET?
> I don't think "everything" or "all" has a meaningful implementation
> available on all compilers.  I was actually saying the opposite.
> We should not try to provide such an abstraction and instead have
> one called "most" or "high" or something like that.
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. Also I think that LEVEL<N>/MOST/ALL groups doesn't make a 
lot of practical sense since every compiler have different kind of 
warnings enabled by such groups, so it's not cross-platformic friendly.

Ruslo