Sounds good?
On 06-Apr-16 01:03, Ruslan Baratov via cmake-developers wrote:
On 05-Apr-16 21:03, Brad King wrote:
On 03/31/2016 12:47 PM, Ruslan Baratov wrote:
What about 3 properties containing list of <warning-id>'s (groups
unexpanded):
* COMPILE_WARNINGS_DISABLE # e.g. "shift-sign-overflow;unused"
* COMPILE_WARNINGS_ENABLE # e.g. "ALL"
* COMPILE_WARNINGS_TREAT_AS_ERROR # e.g. group + specific:
"inline;undef"
We would need to define behavior when a warning appears in more than
one list.
Report an error in case of any type of conflicts. It may happens not
only when same type appears in both DISABLE and ENABLE but for example
when warning already defined by some group. E.g. "EVERYTHING;undef" is
the same as "EVERYTHING". If user okay with having intersections (for
any reason) new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may
control this.
Perhaps we need to define some kind of `=on/off/error/no-error`
syntax for each list entry.
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
?
Second variant looks clearer for me.
The name "ALL" may not be representative. Even -Wall does not really
enable
all possible warnings on some compilers. I'd like to find another
name that
captures the idea of enabling most warnings. Or we could try to
subsume it
into an interface for the warning level, with -Wall considered "high".
Agree. May be EVERYTHING? Or ALLWARNINGS, FULLSET?
I'm not sure about mixing more languages. I think it will be similar to
COMPILE_OPTIONS (?), see no language specification in
`add_compile_options` command.
Right. We do have the COMPILE_LANGUAGE genex for some limited use
cases.
Its documentation even includes a COMPILE_OPTIONS example. However, it
also documents that it is not possible to implement fully on VS IDE
generators. For example, VS does not distinguish between C and C++
flags. The same set is always used for both.
Since /Wall can be set by 'target_compile_options' then abstracting it
by `target_compile_warnings(... ENABLE ALL)` should not be a problem I
think.
Another option is to have the warning names themselves have a language
in them, similar to the COMPILE_FEATURES names.
See no point of this one. So say we have switch-enum warning which is
only for C++, why do we need cxx-switch-enum? There is no
c-switch-enum or any other *-switch-enum. If we are talking about
'undef' why do we need c-undef and cxx-undef? It mean the same and I
think will be set or unset simultaneously.
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
