[cmake-developers] CMake API for warnings

[Geoffrey Viola]

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. 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.

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.

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/20160328/59422268/attachment-0001.html>