Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

This one looks like a plan. However I will not be able to work on the 
feature till ~15 May. So if anybody have a free time to start this work 
- feel free to do it and share patches :)


Thanks, Ruslo

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(

DISABLE  # add =off to COMPILE_WARNINGS
property
ENABLE  # add =on to COMPILE_WARNINGS
property
TREAT_AS_ERROR  # add =error to
COMPILE_WARNINGS property
)

Sounds good.


* all (compiler specific "all", e.g. /Wall or -Wall)
* default
* level
* 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 for now for the reason you outlined.
We can always add it later.


Properties will be set in form =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.


 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



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 26-Apr-16 01:58, Brad King wrote:

On 04/23/2016 12:11 AM, Ruslan Baratov wrote:

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

[snip]

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)

We don't have such a feature for any of the other build settings so
there is no precedent for how to represent this or its exact semantics.


Okay, fair enough, let's skip it.

Ruslo
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Brad King]

On 04/23/2016 12:11 AM, Ruslan Baratov wrote:
> It means ignoring directory properties. So by default we will inherit 
> settings.
[snip]
> 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)

We don't have such a feature for any of the other build settings so
there is no precedent for how to represent this or its exact semantics.

We may not need the capability at all.  For other properties like
COMPILE_OPTIONS and INCLUDE_DIRECTORIES the target-level property
is initialized from the directory-level property when the target
is created.  After that the directory-level property has no meaning
to the target.  One may then set the target-level property to
erase any content previously taken from the directory-level
property.  This allows specific targets to ignore the directory-level
property in special cases.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

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(

DISABLE  # add =off to COMPILE_WARNINGS
property
ENABLE  # add =on to COMPILE_WARNINGS
property
TREAT_AS_ERROR  # add =error to
COMPILE_WARNINGS property
)

Sounds good.


* all (compiler specific "all", e.g. /Wall or -Wall)
* default
* level
* 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 for now for the reason you outlined.
We can always add it later.


Properties will be set in form =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




 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 

Re: [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(
>
>DISABLE  # add =off to COMPILE_WARNINGS 
> property
>ENABLE  # add =on to COMPILE_WARNINGS 
> property
>TREAT_AS_ERROR  # add =error to 
> COMPILE_WARNINGS property
>)

Sounds good.

>* all (compiler specific "all", e.g. /Wall or -Wall)
>* default
>* level
>* 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 for now for the reason you outlined.
We can always add it later.

> Properties will be set in form =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.

> 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

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

So here is a summary of this feature so far:

Introducing new 3 functions for controlling compiler warnings:

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)

Same API for all:

  *_compile_warnings(
  
  DISABLE  # add =off to COMPILE_WARNINGS 
property
  ENABLE  # add =on to COMPILE_WARNINGS 
property
  TREAT_AS_ERROR  # add =error to 
COMPILE_WARNINGS property

  )

General warning-id's:

  * all (compiler specific "all", e.g. /Wall or -Wall)
  * default
  * level
  * none
  * everything (all possible warnings for compiler, if there is no such 
option use maximum level plus some warnings explicitly)


Group warnings-id's:

  * inline # MSVC: 4711 (automatic-inline), 4714 (force-not-inlined), 
4710 (not-inlined), 4514 (unreferenced-inline)
  * compatibility-c++98 # Clang: `-Wc++98-compat`, 
`-Wc++98-compat-pedantic`


Simple warning-id examples:

  * undef  # Clang/GCC: `-Wunder`; MSVC: 4668
  * shift-sign-overflow # Clang: `-Wshift-sign-overflow`, GCC: nothing, 
MSVC: nothing

  * inherits-via-dominance # Clang/GCC: nothing, MSVC: 4250

Since I'm expecting cross-platform behaviour here I think that such 
general warnings-id like 'all', 'default', 'level' might
be confusing since different compilers with the same levels will define 
different groups of warnings (no tests/examples, I'm just pretty sure 
about that).

So I'm afraid we will end with code like this:

  if(MSVC)
add_compile_warnings(ENABLE level3)
  else()
add_compile_warnings(ENABLE level4)
  endif()

I think that goal of this feature is to avoid such compiler specific 
switches.


Note that there is no such problem with 'none', 'everything', 
group/simple warning-id.


Properties will be set in form =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

Generator expressions can be used for config-specific warnings:

  set(debug_off $<$:off>)
  set(non_debug_error $<$:error>)

  set_directory_properties(... COMPILE_WARNINGS 
undef=${debug_off}${non_debug_error} ${old_warnings})


In case of any conflicts return CMake warning for developer message 
(cmake -Wdev/cmake -Wno-dev).


Implementation details:

  Abstracted unmodified  will be kept until the very last 
point when we need real flags generated. E.g. do not expand 'everything' 
on any step since this will

  mask possible configuration errors:

add_compile_warnings(DISABLE all ENABLE undef) # OK: turn off 
everything except 'undef'
add_compile_warnings(DISABLE warning-A warning-B ... undef ... 
warning-Y warning-Z ENABLE undef) # ERROR: user want undef=on and undef=off


  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)' ?


   may expand to nothing in case warning make no sense for 
current language or warning not implemented by compiler:


add_compile_warnings(ENABLE switch-enum)
add_executable(foo foo.c) # C target, no warning will be added
add_executable(boo boo.cpp) # C++ target, -Wswitch-enum will be added

add_compile_warning(ENABLE inherits-via-dominance)
add_executable(foo foo.cpp) # Clang/GCC: nothing, MSVC: 4250

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


Warnings should not be propagated via INTERFACE because unlike 
definitions or other compiler flags they doesn't affect final binary or 
compatibility.


Questions that is not touched so far:

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.
> E.g. when I have CMAKE_POSITION_INDEPENDENT_CODE variable set to 
`YES` I need to add `-fPIC` to the flags manually, or check 
`CXX_STANDARD 11` and add `-std=c++11`. I guess I can handle such simple 
cases but I can predict that for warnings it will be a huge pain.

> How CMake can help me avoid violating DRY?

Would be nice to have this one. Like 'expand_compiler_flags(cxxflags 
LANGUAGE CXX CONFIGURATION Debug)' => add 'CXXFLAGS=${cxxflags}' 

Re: [cmake-developers] CMake API for warnings

[Brad King]

On 04/13/2016 01:20 AM, Ruslan Baratov wrote:
>>> 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)

Sure.

>>> 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
[snip]
> 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:

I realized there is a difference between the low-level plumbing representation
of this in the property values and the porcelain provided by a new command
like target_compile_warnings.  I've been thinking of the plumbing and you've
been thinking of the porcelain.  They do not have to be the same.  The
plumbing could even use 0/1 instead of off/on to work better with a genex.

We need to work out designs for both such that they can work together and
the command can easily map to the internal property representation.  Perhaps
having separate properties for _ENABLE, _DISABLE, and _ERROR is the way to
go, perhaps not.  Either way we can diagnose inconsistent value combinations.

> so how about this:
> 
> compile_warnings(DISABLE foo CONFIGURATION Debug)
> compile_warnings(ERROR foo CONFIGURATION NOT Debug)

I'd prefer to use generator expressions for the per-config values instead
of an explicit CONFIGURATION porcelain, at least at first.

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

Okay.  We can document the "everything" mode as meaning CMake will do
a best-effort to add all warnings the compiler can provide, at least
without resorting to adding lots of individual flags.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

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=$
As far as I understand we should allow on/off/error, so effectively it 
will be:


foo=$<$:off>$<$: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/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
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Brad King]

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.

> 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?  Compilers use flags like

  -Wxyz -Wno-abc -Whjk=error

and not

  -WDISABLE $w1 $w2 -WENABLE $w3 $w4

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=$

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

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

Sounds good?

On 06-Apr-16 01:03, Ruslan Baratov via cmake-developers wrote:

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


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

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

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Brad King]

On 03/31/2016 12:47 PM, Ruslan Baratov wrote:
> What about 3 properties containing list of '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.  Perhaps we need to define some kind of `=on/off/error/no-error`
syntax for each list entry.

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

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

Another option is to have the warning names themselves have a language
in them, similar to the COMPILE_FEATURES names.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

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 $ 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( DISABLE 
ENABLE  TREAT_AS_ERROR ) # 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 '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

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

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Simon Richter]

Hi,

On 27.03.2016 07:10, Geoffrey Viola wrote:

> CMake should support an API to manage compiler warnings to simplify a
> common problem. Using more compilers with high levels of warnings means
> cheap static analysis and better conformance to standard C++.

With my Linux distro hat on: please don't force warning levels from
inside projects.

Packages are often automatically compiled on different platforms, and we
do want to know about third party modules generating warnings on the
more obscure ones where sizeof(long) < sizeof(void *), because no human
will ever have more than a casual look at the build logs unless there
are warnings there that do not appear on other platforms.

With my program maintainer hat on:

What I'd really like to see is cross-platform selection of warning
types. In flex generated code, there are lots of "unused named argument"
warnings from both gcc and cl.exe, which I'd like to turn off exactly
for those generated files, without introducing compiler-specific code,
or overriding the global default from the cmake invocation.

With my continuous integration hat on:

While we're on the topic of warnings: when cmake is re-run because
CMakeLists.txt changed, it would be great to get a list of source/object
files and/or program invocations that vanished. I have a compiler
wrapper that stores the warnings into a database, and fetches warnings
for objects that weren't rebuilt so they are included into the reports,
but this doesn't track source files that were dropped.

   Simon



signature.asc
Description: OpenPGP digital signature
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 28-Mar-16 21:05, Brad King wrote:

On 03/28/2016 01:49 AM, Geoffrey Viola wrote:

Thanks for the feedback. I’ll have to look more in-depth at Xcode specific 
issues.

Take a look at this approach:
* https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

I took a look at your repository. It’s very sophisticated.

I'd prefer to see an approach that abstracts the warning levels
in a similar way to COMPILE_FEATURES, COMPILE_DEFINITIONS,
INCLUDE_DIRECTORIES, etc.  Project code would set directory or
target properties to specify warning levels and the generators
would map them to the proper flags or project file settings
automatically.

Something like this has long been missing for compiler warnings
and optimization levels.

-Brad

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.
E.g. when I have CMAKE_POSITION_INDEPENDENT_CODE variable set to `YES` I 
need to add `-fPIC` to the flags manually, or check `CXX_STANDARD 11` 
and add `-std=c++11`. I guess I can handle such simple cases but I can 
predict that for warnings it will be a huge pain.

How CMake can help me avoid violating DRY?

Ruslo
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 29-Mar-16 21:24, Brad King wrote:

On 03/29/2016 09:09 AM, Ruslan Baratov wrote:

As a general note obviously I've used another approach because I decide
to create CMake module which can be used with regular CMake versions :)
Of course implementing this in CMake "from the box" is best.

Are we talking about levels only or about control of exact kind of
warnings too (like `-Wswitch`/`-wswitch`/`-Werror=switch`)?

At a minimum we should support levels (e.g. all, default, none) that
are generic enough to have mappings to flags on every compiler.  Later
one could consider more granular switches with enumerated options that
may not all have flags on every compiler.



OTOH many such switches are
so specific that they should not be abstracted and can instead be
added to COMPILE_OPTIONS with a $ genex guard.

What about generating nothing for such cases? E.g. code:

  try {
  }
  catch (...) {
  }

produce "catch-semantic-changed" warning on MSVC but it's okay for 
Clang. So we can add `/w4571` for MSVC and nothing for other compilers.




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? Requirements are handy when we are talking about 
different code generated with different compile flags. Warnings have 
different nature. Fact that we are using `-Wall` or not using `-Wall` 
doesn't change final binary or affect compatibility.




Once such directory/target properties are available then we could look
at making them take over the role of providing default warning flags
instead of putting them in the CMAKE__FLAGS* variables.  That may
need a policy as you pointed out earlier.

-Brad

Great.


What about this:

compile_warnings # modify directory properties
target_compile_warnings # modify target properties
sources_compile_warnings # modify source properties

Same API for all:

   *_compile_warnings( DISABLE  
ENABLE  TREAT_AS_ERROR ) # may be plus 'APPEND' 
for extending instead of overwriting (?)


General warning-id's:

  * ALL
  * DEFAULT
  * LEVEL

Group warnings-id's:

  * inline # MSVC: 4711 (automatic-inline), 4714 (force-not-inlined), 
4710 (not-inlined), 4514 (unreferenced-inline)
  * compatibility-c++98 # Clang: `-Wc++98-compat`, 
`-Wc++98-compat-pedantic`


Simple warning-id examples:

  * undef  # Clang/GCC: `-Wunder`; MSVC: 4668
  * shift-sign-overflow # Clang: `-Wshift-sign-overflow`, GCC: nothing, 
MSVC: nothing

  * inherits-via-dominance # Clang/GCC: nothing, MSVC: 4250

Ruslo
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Brad King]

On 03/29/2016 09:09 AM, Ruslan Baratov wrote:
> As a general note obviously I've used another approach because I decide 
> to create CMake module which can be used with regular CMake versions :) 
> Of course implementing this in CMake "from the box" is best.
> 
> Are we talking about levels only or about control of exact kind of 
> warnings too (like `-Wswitch`/`-wswitch`/`-Werror=switch`)?

At a minimum we should support levels (e.g. all, default, none) that
are generic enough to have mappings to flags on every compiler.  Later
one could consider more granular switches with enumerated options that
may not all have flags on every compiler.  OTOH many such switches are
so specific that they should not be abstracted and can instead be
added to COMPILE_OPTIONS with a $ genex guard.

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.

Once such directory/target properties are available then we could look
at making them take over the role of providing default warning flags
instead of putting them in the CMAKE__FLAGS* variables.  That may
need a policy as you pointed out earlier.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 28-Mar-16 12:49, Geoffrey Viola wrote:


Thanks for the feedback. I’ll have to look more in-depth at Xcode 
specific issues.


> Take a look at this approach:
> * https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

I took a look at your repository. It’s very sophisticated.

What exactly is sophisticated? API of `sugar_generate_warning_flags` 
function? Probably this is because it covering much more functionality 
that your approach, no? Also you can use this to create new function 
with more simple API. That is you can make `set_warning_level_high` 
using call to `sugar_generate_warning_flags` but there is no function 
(at least in the currently attached patch) that can set `-Wall` in 
cross-platform fashion for only one target.


The API that I’m supporting has global commands for simple, small 
projects and then a slightly more sophisticated set of commands around 
targets and source files. It’s supposed to remove the need of knowing 
compiler specific flags from the user, although they can be manually 
edited in CMake as always.


May be I'm missing something but there is no need to know compiler 
specific flags when using `sugar_generate_warning_flags`. In sense that 
when you set `conversion` then module will add `-Wconversion` for Clang 
and GCC, `4244` for MSVC and CLANG_WARN_SUSPICIOUS_IMPLICIT_CONVERSION 
for Xcode. From my practice there must be an abstraction that is linked 
to the exact type of warning because without `-Werror` warnings are 
quite useless and if you combine it with `-Wall -Weverything` there will 
be a lot of warning that I don't want to fix, like `-Wpadded` that 
produce warning like for every C++ class definition in the project.


The choice of flags for the various compilers are different between 
the two APIs. My API merely turns the warnings up without triggering 
false positives. It may miss some useful warnings. For example, my API 
uses /W4 instead of /Wall for MSVC. I’ve seen /Wall provide some 
additional useful warnings, but also some distracting, informational 
ones. There are a few users who agree that some of the /Wall warnings 
are more informational at 
http://stackoverflow.com/questions/4001736/whats-up-with-the-thousands-of-warnings-in-standard-headers-in-msvc-wall. 
Also, I should probably include –Wextra for the GCC warnings like 
yours does.


I think you should not make such decisions in code like "I know that /W4 
is better than /Wall" or "I'm sure -Wshadow is useless". That definitely 
up to user.


Ruslo


From: Ruslan Baratov [mailto:ruslan_bara...@yahoo.com]
Sent: Sunday, March 27, 2016 4:17 PM
To: Geoffrey Viola <geoffrey.vi...@asirobots.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] CMake API for warnings

I like an effort but not an implementation:
* It would be nice to not to set flags globally since we have more 
fine control options like target_compile_options (i.e. different 
target may have different warning settings)
* this will not work for Xcode since warnings should be set by 
XCODE_ATTRIBUTE_* properties


Take a look at this approach:
* https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

Though I think it should be simplified. Best implementation I see so far:
* Remove `RESULT_PROPERTIES`:  implement warning flags -> 
XCODE_ATTRIBUTE_* mapping in CMake itself
* Remove `CLEAR_GLOBAL` option: add user variable checking to CMake so 
it will not set `/W3` (or any other warning flags) by default. May be 
introduce new policy (?)


Ruslo

On 27-Mar-16 12:10, Geoffrey Viola wrote:

CMake should support an API to manage compiler warnings to simplify a 
common problem. Using more compilers with high levels of warnings 
means cheap static analysis and better conformance to standard C++.


Compiler warnings are an easy way to increase program reliability. A 
use case would be to increase compilation warnings on all internal 
code, ignore warnings on all 3rd party code, and treat all warnings as 
errors.


Attached is an initial attempt to control warnings in CMake. The API 
has a short name (e.g. set_warnings_as_errors) for simplicity and a 
more technical name (e.g. set_warnings_as_errors_folder) to specify 
scope. Note that the short name acts on CMake’s folder scope and is 
meant to be global. The current compilers considered are GCC, clang, 
Green Hills, and MSVC. A CMake Warning is issued if the macro does not 
support a specific compiler so that conformance can be guaranteed.


Thanks,

Geoffrey Viola

This message contains confidential information and is intended only 
for the recipient. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately if you have received this e-mail by mistake and delete 
this e-mail from your system. Finally, the recipient should check this 
email and any attachments for the presence of viruses. The company 
accepts no liability

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

On 28-Mar-16 21:05, Brad King wrote:

On 03/28/2016 01:49 AM, Geoffrey Viola wrote:

Thanks for the feedback. I’ll have to look more in-depth at Xcode specific 
issues.

Take a look at this approach:
* https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

I took a look at your repository. It’s very sophisticated.

I'd prefer to see an approach that abstracts the warning levels
in a similar way to COMPILE_FEATURES, COMPILE_DEFINITIONS,
INCLUDE_DIRECTORIES, etc.  Project code would set directory or
target properties to specify warning levels and the generators
would map them to the proper flags or project file settings
automatically.
As a general note obviously I've used another approach because I decide 
to create CMake module which can be used with regular CMake versions :) 
Of course implementing this in CMake "from the box" is best.


Are we talking about levels only or about control of exact kind of 
warnings too (like `-Wswitch`/`-wswitch`/`-Werror=switch`)?


Ruslo



Something like this has long been missing for compiler warnings
and optimization levels.

-Brad



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Brad King]

On 03/28/2016 01:49 AM, Geoffrey Viola wrote:
> Thanks for the feedback. I’ll have to look more in-depth at Xcode specific 
> issues.
>> Take a look at this approach:
>> * https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression
> 
> I took a look at your repository. It’s very sophisticated.

I'd prefer to see an approach that abstracts the warning levels
in a similar way to COMPILE_FEATURES, COMPILE_DEFINITIONS,
INCLUDE_DIRECTORIES, etc.  Project code would set directory or
target properties to specify warning levels and the generators
would map them to the proper flags or project file settings
automatically.

Something like this has long been missing for compiler warnings
and optimization levels.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Geoffrey Viola]

Thanks for the feedback. I'll have to look more in-depth at Xcode specific 
issues.

> Take a look at this approach:
> * https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression
I took a look at your repository. It's very sophisticated. The API that I'm 
supporting has global commands for simple, small projects and then a slightly 
more sophisticated set of commands around targets and source files. It's 
supposed to remove the need of knowing compiler specific flags from the user, 
although they can be manually edited in CMake as always.

The choice of flags for the various compilers are different between the two 
APIs. My API merely turns the warnings up without triggering false positives. 
It may miss some useful warnings. For example, my API uses /W4 instead of /Wall 
for MSVC. I've seen /Wall provide some additional useful warnings, but also 
some distracting, informational ones. There are a few users who agree that some 
of the /Wall warnings are more informational at 
http://stackoverflow.com/questions/4001736/whats-up-with-the-thousands-of-warnings-in-standard-headers-in-msvc-wall.
 Also, I should probably include -Wextra for the GCC warnings like yours does.

From: Ruslan Baratov [mailto:ruslan_bara...@yahoo.com]
Sent: Sunday, March 27, 2016 4:17 PM
To: Geoffrey Viola <geoffrey.vi...@asirobots.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] CMake API for warnings

I like an effort but not an implementation:
* It would be nice to not to set flags globally since we have more fine control 
options like target_compile_options (i.e. different target may have different 
warning settings)
* this will not work for Xcode since warnings should be set by 
XCODE_ATTRIBUTE_* properties

Take a look at this approach:
* https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

Though I think it should be simplified. Best implementation I see so far:
* Remove `RESULT_PROPERTIES`:  implement warning flags -> XCODE_ATTRIBUTE_* 
mapping in CMake itself
* Remove `CLEAR_GLOBAL` option: add user variable checking to CMake so it will 
not set `/W3` (or any other warning flags) by default. May be introduce new 
policy (?)

Ruslo

On 27-Mar-16 12:10, Geoffrey Viola wrote:
CMake should support an API to manage compiler warnings to simplify a common 
problem. Using more compilers with high levels of warnings means cheap static 
analysis and better conformance to standard C++.

Compiler warnings are an easy way to increase program reliability. A use case 
would be to increase compilation warnings on all internal code, ignore warnings 
on all 3rd party code, and treat all warnings as errors.

Attached is an initial attempt to control warnings in CMake. The API has a 
short name (e.g. set_warnings_as_errors) for simplicity and a more technical 
name (e.g. set_warnings_as_errors_folder) to specify scope. Note that the short 
name acts on CMake's folder scope and is meant to be global. The current 
compilers considered are GCC, clang, Green Hills, and MSVC. A CMake Warning is 
issued if the macro does not support a specific compiler so that conformance 
can be guaranteed.

Thanks,
Geoffrey Viola
This message contains confidential information and is intended only for the 
recipient. If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately if you 
have received this e-mail by mistake and delete this e-mail from your system. 
Finally, the recipient should check this email and any attachments for the 
presence of viruses. The company accepts no liability for any damage caused by 
any virus transmitted by this email.


This message contains confidential information and is intended only for the 
recipient. If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately if you 
have received this e-mail by mistake and delete this e-mail from your system. 
Finally, the recipient should check this email and any attachments for the 
presence of viruses. The company accepts no liability for any damage caused by 
any virus transmitted by this email.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

I like an effort but not an implementation:
* It would be nice to not to set flags globally since we have more fine 
control options like target_compile_options (i.e. different target may 
have different warning settings)
* this will not work for Xcode since warnings should be set by 
XCODE_ATTRIBUTE_* properties


Take a look at this approach:
* https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression

Though I think it should be simplified. Best implementation I see so far:
* Remove `RESULT_PROPERTIES`:  implement warning flags -> 
XCODE_ATTRIBUTE_* mapping in CMake itself
* Remove `CLEAR_GLOBAL` option: add user variable checking to CMake so 
it will not set `/W3` (or any other warning flags) by default. May be 
introduce new policy (?)


Ruslo

On 27-Mar-16 12:10, Geoffrey Viola wrote:


CMake should support an API to manage compiler warnings to simplify a 
common problem. Using more compilers with high levels of warnings 
means cheap static analysis and better conformance to standard C++.


Compiler warnings are an easy way to increase program reliability. A 
use case would be to increase compilation warnings on all internal 
code, ignore warnings on all 3^rd party code, and treat all warnings 
as errors.


Attached is an initial attempt to control warnings in CMake. The API 
has a short name (e.g. set_warnings_as_errors) for simplicity and a 
more technical name (e.g. set_warnings_as_errors_folder) to specify 
scope. Note that the short name acts on CMake’s folder scope and is 
meant to be global. The current compilers considered are GCC, clang, 
Green Hills, and MSVC. A CMake Warning is issued if the macro does not 
support a specific compiler so that conformance can be guaranteed.


Thanks,

Geoffrey Viola

This message contains confidential information and is intended only 
for the recipient. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately if you have received this e-mail by mistake and delete 
this e-mail from your system. Finally, the recipient should check this 
email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by 
this email.





-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] CMake API for warnings

[Geoffrey Viola]

CMake should support an API to manage compiler warnings to simplify a common 
problem. Using more compilers with high levels of warnings means cheap static 
analysis and better conformance to standard C++.

Compiler warnings are an easy way to increase program reliability. A use case 
would be to increase compilation warnings on all internal code, ignore warnings 
on all 3rd party code, and treat all warnings as errors.

Attached is an initial attempt to control warnings in CMake. The API has a 
short name (e.g. set_warnings_as_errors) for simplicity and a more technical 
name (e.g. set_warnings_as_errors_folder) to specify scope. Note that the short 
name acts on CMake's folder scope and is meant to be global. The current 
compilers considered are GCC, clang, Green Hills, and MSVC. A CMake Warning is 
issued if the macro does not support a specific compiler so that conformance 
can be guaranteed.

Thanks,
Geoffrey Viola
This message contains confidential information and is intended only for the 
recipient. If you are not the named addressee you should not disseminate, 
distribute or copy this e-mail. Please notify the sender immediately if you 
have received this e-mail by mistake and delete this e-mail from your system. 
Finally, the recipient should check this email and any attachments for the 
presence of viruses. The company accepts no liability for any damage caused by 
any virus transmitted by this email.


0001-added-common-warning-level-macros.patch
Description: 0001-added-common-warning-level-macros.patch
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers