On 31-Mar-16 20:37, Brad King wrote:
On 03/29/2016 11:24 AM, Ruslan Baratov wrote:
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.
What about generating nothing for such cases?
Yes, that makes sense. I was just discussing alternatives. Simon's
post contains an example of a granular flag that makes sense to try
to abstract.
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.
But not if target is installed. It will be quite inconvenient if 3rd
party package add some flags to local targets. Is it possible to support
it from the box?
Yes, let's skip propagation until a valid use case is raised in the
future, if any. Likely the directory properties can be used to specify
project-wide warning configurations without propagating across targets.
Great.
What about this:
compile_warnings # modify directory properties
target_compile_warnings # modify target properties
sources_compile_warnings # modify source properties
Let's start by getting the directory/target/source properties worked
out. First we need to figure out how to make the properties work with
language-specific warning flags and such. We can add command porcelain
for them later.
Same API for all:
*_compile_warnings(<global/target/source> DISABLE <warning-id>
ENABLE <warning-id> TREAT_AS_ERROR <warning-id>) # may be plus 'APPEND'
for extending instead of overwriting (?)
Somehow this needs to be encoded in a COMPILE_WARNINGS property or
group of properties. They should support generator expressions for
per-configuration warnings.
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"
I don't know how it will happen in CMake's internals but I think at the
point of generating the real flags we know the language of the
source/target and can exclude language specific warnings. I.e. if
'switch-enum' is set for C++ target we can generate '-Wswitch-enum' but
if target is pure C we will add no flags.
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.
General warning-id's:
* ALL
* DEFAULT
* LEVEL<N>
And `NONE`.
Ok
Group warnings-id's:
Yes, but either the warning names or the property names will need to
allow for language-specific warnings. We need to be able to control
warnings for C, C++, Fortran, etc. separately. OTOH it would also
be nice to be able to set C and C++ warnings together since many of
them are common.
Ideas?
See above.
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
