[cmake-developers] CMake API for warnings

Ruslan Baratov ruslan_baratov at yahoo.com
Thu Mar 31 12:47:04 EDT 2016


On 31-Mar-16 20:37, Brad King wrote:
> On 03/29/2016 11:24 AM, Ruslan Baratov wrote:
>>> OTOH many such switches are
>>> so specific that they should not be abstracted and can instead be
>>> added to COMPILE_OPTIONS with a $<C_COMPILER_ID:...> genex guard.
>> What about generating nothing for such cases?
> Yes, that makes sense.  I was just discussing alternatives.  Simon's
> post contains an example of a granular flag that makes sense to try
> to abstract.
>
>>> I think these warning properties should perhaps be done as usage
>>> requirements with propagation through INTERFACE_* properties.  I'd
>>> need to see some example use cases spelled out though.
>> But not if target is installed. It will be quite inconvenient if 3rd
>> party package add some flags to local targets. Is it possible to support
>> it from the box?
> Yes, let's skip propagation until a valid use case is raised in the
> future, if any.  Likely the directory properties can be used to specify
> project-wide warning configurations without propagating across targets.

Great.

>> What about this:
>>
>>       compile_warnings # modify directory properties
>>       target_compile_warnings # modify target properties
>>       sources_compile_warnings # modify source properties
> Let's start by getting the directory/target/source properties worked
> out.  First we need to figure out how to make the properties work with
> language-specific warning flags and such.  We can add command porcelain
> for them later.
>
>> Same API for all:
>>
>>      *_compile_warnings(<global/target/source> DISABLE <warning-id>
>> ENABLE <warning-id> TREAT_AS_ERROR <warning-id>) # may be plus 'APPEND'
>> for extending instead of overwriting (?)
> Somehow this needs to be encoded in a COMPILE_WARNINGS property or
> group of properties.  They should support generator expressions for
> per-configuration warnings.

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"

I don't know how it will happen in CMake's internals but I think at the 
point of generating the real flags we know the language of the 
source/target and can exclude language specific warnings. I.e. if 
'switch-enum' is set for C++ target we can generate '-Wswitch-enum' but 
if target is pure C we will add no flags.

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.

>> General warning-id's:
>>
>>     * ALL
>>     * DEFAULT
>>     * LEVEL<N>
> And `NONE`.

Ok

>
>> Group warnings-id's:
> Yes, but either the warning names or the property names will need to
> allow for language-specific warnings.  We need to be able to control
> warnings for C, C++, Fortran, etc. separately.  OTOH it would also
> be nice to be able to set C and C++ warnings together since many of
> them are common.
>
> Ideas?

See above.

Ruslo


More information about the cmake-developers mailing list