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