[cmake-developers] CMake API for warnings
Ruslan Baratov
ruslan_baratov at yahoo.com
Tue Mar 29 09:09:33 EDT 2016
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_baratov at yahoo.com]
> Sent: Sunday, March 27, 2016 4:17 PM
> To: Geoffrey Viola <Geoffrey.Viola at asirobots.com>
> Cc: cmake-developers at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20160329/b812a164/attachment-0001.html>
More information about the cmake-developers
mailing list