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 $<C_COMPILER_ID:...> 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_<LANG>_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
