On 13-Apr-16 01:00, Brad King wrote:
Hi Ruslo,
Sorry for taking so long to respond here. I've been hoping to find time
to think through the design deeply but I don't know when that may happen.
Here is some more feedback. I invite others to jump in here. Without
more interest I'm hesitant to proceed.
On 04/05/2016 02:03 PM, Ruslan Baratov wrote:
Report an error in case of any type of conflicts.
Yes.
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)
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
Consider examples where we don't have the full list ahead of time and
are instead appending.
-
Or, what if we want to check the current property
value to see if some setting is already present?
What do you mean?
Compilers use flags like
-Wxyz -Wno-abc -Whjk=error
and not
-WDISABLE $w1 $w2 -WENABLE $w3 $w4
I don't think the reason of approach used in compilers is about been
convenient for user to analyze command line flags. CMake can do much
better job here.
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:
function(enable_warnings_list ...)
foreach(warning ...)
list(APPEND result ${warning}=on)
endforeach()
endif()
So instead of writing extra different modules by a lot of developers why
not support this from the box?
so IMO the individual values are easier to reason about. Also one could
imagine having the value come from a generator expression, e.g.
foo=$<CONFIG:Debug>
As far as I understand we should allow on/off/error, so effectively it
will be:
foo=$<$<CONFIG:Debug>:off>$<$<NOT:$<CONFIG:Debug>>:error>
so how about this:
compile_warnings(DISABLE foo CONFIGURATION Debug)
compile_warnings(ERROR foo CONFIGURATION NOT Debug)
?
I'd like to find another name that captures the idea of enabling most warnings.
Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET?
I don't think "everything" or "all" has a meaningful implementation
available on all compilers. I was actually saying the opposite.
We should not try to provide such an abstraction and instead have
one called "most" or "high" or something like that.
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. Also I think that LEVEL<N>/MOST/ALL groups doesn't make a
lot of practical sense since every compiler have different kind of
warnings enabled by such groups, so it's not cross-platformic friendly.
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
