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