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(
<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
)
General warning-id's:
* 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)
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<N>' 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 <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
Generator expressions can be used for config-specific warnings:
set(debug_off $<$<CONFIG:Debug>:off>)
set(non_debug_error $<$<NOT:$<CONFIG:Debug>>: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 <warning-id> 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)' ?
<warning-id> 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}' to
ExternalProject_Add step of autotools based project.
On 31-Mar-16 04:31, Simon Richter wrote:
>
> 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.
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?
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
