Re: [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_bara...@yahoo.com]
Sent: Sunday, March 27, 2016 4:17 PM
To: Geoffrey Viola 
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

Re: [cmake-developers] [PATCH SET] Support of Clang/C2 compiler

[Mariusz Pluciński]

Hi,

Sorry for a bit late answer.


2016-03-09 15:37 GMT+01:00 Brad King :

> On 02/27/2016 09:38 AM, Mariusz Pluciński wrote:
> > Following is the list of patches with descriptions:
>
> Thanks!
>

You're welcome!


> > 11. Tests: do not build ExternalProjectLocal/TutorialStep5 when path is
> too long
> > This toolset uses a bit longer names of some files, which may cause full
> path size to exceed 256 characters.
>
> The condition for this one needs to be thought out a bit more.
> We no longer support Windows 98 so the old condition can simply
> be replaced.  I expect it applies to all Windows versions anyway.
> Anyway, this is mostly orthogonal to Clang/C2 support.
>

In general it's orthogonal. The reason why I put it there was that in my
case, it was the switch to Clang/C2 that caused the issue. It seems that
when this toolkit is in use, some of the temporary files and directories
have a bit longer names. The direct cause for these failures was some of
.tlog files that got full path longer than 256 characters - when I moved
the project nearer to root directory, these were compiling successfully.

That said, rerunning this test in shorter path had succeeded. I don't know
if it's worth to modify the CMake code to detect such situation, although
these failures seem quite mysterious - the compiler or MSBuild just fails
without detailed error message.


> > 8. Tests: fix Module.WriteCompilerDetectionHeader building on Clang/C2
> > Visual Studio does not handle this test very well. Not sure why.
> >
> > 15. Tests: disable VSMidl on Clang/C2
> > I don't know why this test fails.
>
> I'm going to let these fail for now until someone has time to investigate
> them more.
>

I see. I didn't know, how do you handle that situations in CMake project.


>
> Would you be able to run nightly testing with this generator/compiler?
> Instructions are here:
>
>  https://cmake.org/Wiki/CMake/Git/Dashboard
>
>
Sure I can. I have set it up today (
https://open.cdash.org/viewSite.php?siteid=17356 ), and now, it seems that
there're some more failures that I saw while running these tests before.
I'm going to take a look on them and fix them if I manage to do so.

Best Regards
Mariusz Plucinski
-- 

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

Re: [cmake-developers] CMake API for warnings

[Ruslan Baratov via cmake-developers]

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 3^rd 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.





-- 

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