[cmake-developers] CMake API for warnings

[Ruslan Baratov]

On 22-Apr-16 20:36, Brad King wrote:
> On 04/20/2016 09:50 AM, Ruslan Baratov wrote:
>> 1) add_compile_warnings
>>     * similar to add_definitions, add_compile_options
>>     * modify COMPILE_WARNINGS directory property (append)
>> 2) target_compile_warnings
>>     * similar to target_compile_options, target_compile_definitions
>>     * modify COMPILE_WARNINGS target property (append)
>> 3) source_files_compile_warnings
>>     * similar to set_source_files_properties
>>     * modify COMPILE_WARNINGS sources property (append)
> Sounds good.  Note that cmTarget has dedicated storage with backtrace
> information for other build system properties.  Please use the same
> pattern for these.  I also suggest getting the directory/target level
> working first and work on source files later.  The infrastructure for
> the latter is not as mature so it may need more work.
>
>>     *_compile_warnings(
>>         <global/target/source>
>>         DISABLE <warning-id> # add <warning-id>=off to COMPILE_WARNINGS
>> property
>>         ENABLE <warning-id> # add <warning-id>=on to COMPILE_WARNINGS
>> property
>>         TREAT_AS_ERROR <warning-id> # add <warning-id>=error to
>> COMPILE_WARNINGS property
>>     )
> Sounds good.
>
>>     * all (compiler specific "all", e.g. /Wall or -Wall)
>>     * default
>>     * level<N>
>>     * none
>>     * everything (all possible warnings for compiler, if there is no such
>> option use maximum level plus some warnings explicitly)
> Okay.  Let's drop level<N> for now for the reason you outlined.
> We can always add it later.
>
>> Properties will be set in form <warning-id>=on|off|error, e.g.:
>>
>>     add_compile_warnings(DISABLE undef unused ENABLE inline TREAT_AS_ERROR everything)
>>
>> will set COMPILE_WARNINGS directory property to:
>>
>>     undef=off unused=off inline=on everything=error
> Good.
>
>> In case of any conflicts return CMake warning for developer message
>> (cmake -Wdev/cmake -Wno-dev).
> Good.
>
>>     Directory properties affect targets and sources, target properties
>> affect sources of this target. E.g.:
>>
>>       add_compile_warnings(DISABLE undef)
>>       target_compile_warnings(foo DISABLE unused)
>>
>>     effectively equivalent to:
>>
>>       target_compile_warnings(foo DISABLE undef unused)
>>
>>     Question: do we need to control this? probably by
>> 'target_compile_warnings(foo DISABLE unused IGNORE DIRECTORY)' ?
> It should be possible to merge the directory/target/source settings
> with proper precedence.  I don't understand your example well enough
> to see what "IGNORE DIRECTORY" would mean.  Either way, such information
> needs to be encoded somehow in the property values.

It means ignoring directory properties. So by default we will inherit 
settings. Target will inherit directory properties:

     add_compile_warnings(DISABLE warn-A)
     target_compile_warnings(foo DISABLE warn-B)

COMPILE_WARNINGS of target 'foo' property value:

     warn-A=off warn-B=off

Sources:

     add_compile_warnings(ENABLE warn-A)
     target_compile_warnings(foo ENABLE warn-B)
     source_files_compile_warnings(foo.cpp ENABLE warn-C)

COMPILE_WARNINGS of 'foo.cpp' property value:

     warn-A=on warn-B=on warn-C=on

To disable inheriting we need to add extra argument (?) to 
*_compile_warnings:

     add_compile_warnings(DISABLE warn-A)
     target_compile_warnings(foo DISABLE warn-B IGNORE DIRECTORY)

COMPILE_WARNINGS of target 'foo' property value (warn-A from directory 
properties ignored):

     warn-B=off

Same with IGNORE TARGET:

     add_compile_warnings(ENABLE warn-A)
     target_compile_warnings(foo ENABLE warn-B)
     source_files_compile_warnings(foo.cpp ENABLE warn-C IGNORE TARGET)

COMPILE_WARNINGS of 'foo.cpp' property value (warn-B from target 
ignored, directory not):

     warn-C=on warn-A=on

Ignoring both:

     add_compile_warnings(ENABLE warn-A)
     target_compile_warnings(foo ENABLE warn-B)
     source_files_compile_warnings(foo.cpp ENABLE warn-C IGNORE TARGET 
DIRECTORY)

Result:

     warn-C=on

>
>>     <warning-id> may expand to nothing in case warning make no sense for
>> current language or warning not implemented by compiler:
> Okay.
>
>> After this feature implemented we need to introduce new policy to avoid
>> adding warnings flags to CMAKE_CXX_FLAGS by default (e.g. "/W3" added by
>> default for Visual Studio).
> Yes.
>
>> Warnings should not be propagated via INTERFACE because unlike
>> definitions or other compiler flags they doesn't affect final binary or
>> compatibility.
> Okay.
>
>> On 29-Mar-16 22:42, Ruslan Baratov wrote:
>>> One more note. Properties is a good abstraction and works great for
>>> the native CMake project. But there is a tricky scenario about them -
>>> when we need to create ExternalProject_Add for the non-CMake project.
>> Would be nice to have this one.
> This is beyond the scope of this change and affects all flags, so
> let's defer this for a later time.
>
>> Is it possible in general to control warnings globally? Imagine I have
>> target that should ignore all warnings for any reason. If you able to
>> control warnings globally this target will generate tons of useless
>> messages. How to enable warnings for all targets except this one?
> This thread has not yet designed any means for a user to control
> warnings globally (e.g. via a cache entry).  Project code should
> be able to offer such options manually, but it would also be nice
> to have a CMake-defined setting.  The semantics of such a setting
> will need to be defined carefully to allow the project to override
> (or not override) settings for specific targets.