[cmake-developers] CMake API for warnings

[Brad King]

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.

>    <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.

-Brad