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
