On 28-Mar-16 12:49, Geoffrey Viola wrote:
Thanks for the feedback. I’ll have to look more in-depth at Xcode
specific issues.
> Take a look at this approach:
> * https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression
I took a look at your repository. It’s very sophisticated.
What exactly is sophisticated? API of `sugar_generate_warning_flags`
function? Probably this is because it covering much more functionality
that your approach, no? Also you can use this to create new function
with more simple API. That is you can make `set_warning_level_high`
using call to `sugar_generate_warning_flags` but there is no function
(at least in the currently attached patch) that can set `-Wall` in
cross-platform fashion for only one target.
The API that I’m supporting has global commands for simple, small
projects and then a slightly more sophisticated set of commands around
targets and source files. It’s supposed to remove the need of knowing
compiler specific flags from the user, although they can be manually
edited in CMake as always.
May be I'm missing something but there is no need to know compiler
specific flags when using `sugar_generate_warning_flags`. In sense that
when you set `conversion` then module will add `-Wconversion` for Clang
and GCC, `4244` for MSVC and CLANG_WARN_SUSPICIOUS_IMPLICIT_CONVERSION
for Xcode. From my practice there must be an abstraction that is linked
to the exact type of warning because without `-Werror` warnings are
quite useless and if you combine it with `-Wall -Weverything` there will
be a lot of warning that I don't want to fix, like `-Wpadded` that
produce warning like for every C++ class definition in the project.
The choice of flags for the various compilers are different between
the two APIs. My API merely turns the warnings up without triggering
false positives. It may miss some useful warnings. For example, my API
uses /W4 instead of /Wall for MSVC. I’ve seen /Wall provide some
additional useful warnings, but also some distracting, informational
ones. There are a few users who agree that some of the /Wall warnings
are more informational at
http://stackoverflow.com/questions/4001736/whats-up-with-the-thousands-of-warnings-in-standard-headers-in-msvc-wall.
Also, I should probably include –Wextra for the GCC warnings like
yours does.
I think you should not make such decisions in code like "I know that /W4
is better than /Wall" or "I'm sure -Wshadow is useless". That definitely
up to user.
Ruslo
From: Ruslan Baratov [mailto:ruslan_bara...@yahoo.com]
Sent: Sunday, March 27, 2016 4:17 PM
To: Geoffrey Viola <geoffrey.vi...@asirobots.com>
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] CMake API for warnings
I like an effort but not an implementation:
* It would be nice to not to set flags globally since we have more
fine control options like target_compile_options (i.e. different
target may have different warning settings)
* this will not work for Xcode since warnings should be set by
XCODE_ATTRIBUTE_* properties
Take a look at this approach:
* https://github.com/ruslo/sugar/wiki/Cross-platform-warning-suppression
Though I think it should be simplified. Best implementation I see so far:
* Remove `RESULT_PROPERTIES`: implement warning flags ->
XCODE_ATTRIBUTE_* mapping in CMake itself
* Remove `CLEAR_GLOBAL` option: add user variable checking to CMake so
it will not set `/W3` (or any other warning flags) by default. May be
introduce new policy (?)
Ruslo
On 27-Mar-16 12:10, Geoffrey Viola wrote:
CMake should support an API to manage compiler warnings to simplify a
common problem. Using more compilers with high levels of warnings
means cheap static analysis and better conformance to standard C++.
Compiler warnings are an easy way to increase program reliability. A
use case would be to increase compilation warnings on all internal
code, ignore warnings on all 3rd party code, and treat all warnings as
errors.
Attached is an initial attempt to control warnings in CMake. The API
has a short name (e.g. set_warnings_as_errors) for simplicity and a
more technical name (e.g. set_warnings_as_errors_folder) to specify
scope. Note that the short name acts on CMake’s folder scope and is
meant to be global. The current compilers considered are GCC, clang,
Green Hills, and MSVC. A CMake Warning is issued if the macro does not
support a specific compiler so that conformance can be guaranteed.
Thanks,
Geoffrey Viola
This message contains confidential information and is intended only
for the recipient. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately if you have received this e-mail by mistake and delete
this e-mail from your system. Finally, the recipient should check this
email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by
this email.
This message contains confidential information and is intended only
for the recipient. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately if you have received this e-mail by mistake and delete
this e-mail from your system. Finally, the recipient should check this
email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by
this email.
--
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
