Here is the case when such feature might be useful:
stackoverflow.com/questions/37036690
Ruslo
On 25-Apr-16 21:58, Brad King wrote:
On 04/23/2016 12:11 AM, Ruslan Baratov wrote:
It means ignoring directory properties. So by default we will inherit settings.
[snip]
To disable inheriting we n
This one looks like a plan. However I will not be able to work on the
feature till ~15 May. So if anybody have a free time to start this work
- feel free to do it and share patches :)
Thanks, Ruslo
On 22-Apr-16 20:36, Brad King wrote:
On 04/20/2016 09:50 AM, Ruslan Baratov wrote:
1) add_comp
On 26-Apr-16 01:58, Brad King wrote:
On 04/23/2016 12:11 AM, Ruslan Baratov wrote:
It means ignoring directory properties. So by default we will inherit settings.
[snip]
To disable inheriting we need to add extra argument (?) to *_compile_warnings:
add_compile_warnings(DISABLE warn-A)
On 04/23/2016 12:11 AM, Ruslan Baratov wrote:
> It means ignoring directory properties. So by default we will inherit
> settings.
[snip]
> To disable inheriting we need to add extra argument (?) to *_compile_warnings:
>
> add_compile_warnings(DISABLE warn-A)
> target_compile_warnings(fo
On 22-Apr-16 20:36, Brad King wrote:
On 04/20/2016 09:50 AM, Ruslan Baratov wrote:
1) add_compile_warnings
* similar to add_definitions, add_compile_options
* modify COMPILE_WARNINGS directory property (append)
2) target_compile_warnings
* similar to target_compile_options, target_co
On 04/20/2016 09:50 AM, Ruslan Baratov wrote:
> 1) add_compile_warnings
>* similar to add_definitions, add_compile_options
>* modify COMPILE_WARNINGS directory property (append)
> 2) target_compile_warnings
>* similar to target_compile_options, target_compile_definitions
>* modify C
So here is a summary of this feature so far:
Introducing new 3 functions for controlling compiler warnings:
1) add_compile_warnings
* similar to add_definitions, add_compile_options
* modify COMPILE_WARNINGS directory property (append)
2) target_compile_warnings
* similar to target_compile
On 04/13/2016 01:20 AM, Ruslan Baratov wrote:
>>> new variable like CMAKE_CHECK_WARNINGS_CONFLICTS=OFF may control this.
>> I'd prefer to avoid extra knobs if possible.
> Okay, what about CMake warning for developer? (cmake -Wdev/cmake -Wno-dev)
Sure.
>>> You mean this:
>>>
>>> compatibilit
On 13-Apr-16 01:00, Brad King wrote:
Hi Ruslo,
Sorry for taking so long to respond here. I've been hoping to find time
to think through the design deeply but I don't know when that may happen.
Here is some more feedback. I invite others to jump in here. Without
more interest I'm hesitant to p
Hi Ruslo,
Sorry for taking so long to respond here. I've been hoping to find time
to think through the design deeply but I don't know when that may happen.
Here is some more feedback. I invite others to jump in here. Without
more interest I'm hesitant to proceed.
On 04/05/2016 02:03 PM, Ruslan
Sounds good?
On 06-Apr-16 01:03, Ruslan Baratov via cmake-developers wrote:
On 05-Apr-16 21:03, Brad King wrote:
On 03/31/2016 12:47 PM, Ruslan Baratov wrote:
What about 3 properties containing list of 's (groups
unexpanded):
* COMPILE_WARNINGS_DISABLE # e.g. "shift-sign-overflow;unused"
* CO
On 05-Apr-16 21:03, Brad King wrote:
On 03/31/2016 12:47 PM, Ruslan Baratov wrote:
What about 3 properties containing list of '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. gr
On 03/31/2016 12:47 PM, Ruslan Baratov wrote:
> What about 3 properties containing list of '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;und
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 $ genex guard.
What about generating nothing for such cases?
Yes, that makes sense.
>> General warning-id's:
>>
>>* ALL
>>* DEFAULT
>>* LEVEL
>
>And `NONE`.
I'm less interested in all warnings and more interested in a clear level that
is the highest warning level that does not provide false positives is. After
setting the warning level precisely, the next step is se
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 $ genex guard.
> What about generating nothing for such cases?
Yes, that makes sense. I was just discussing alternat
Hi,
On 27.03.2016 07: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++.
With my Linux distro hat on: please don
On 28-Mar-16 21:05, Brad King wrote:
On 03/28/2016 01:49 AM, 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 re
On 29-Mar-16 21:24, Brad King wrote:
On 03/29/2016 09:09 AM, Ruslan Baratov wrote:
As a general note obviously I've used another approach because I decide
to create CMake module which can be used with regular CMake versions :)
Of course implementing this in CMake "from the box" is best.
Are we
On 03/29/2016 09:09 AM, Ruslan Baratov wrote:
> As a general note obviously I've used another approach because I decide
> to create CMake module which can be used with regular CMake versions :)
> Of course implementing this in CMake "from the box" is best.
>
> Are we talking about levels only or
-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)
* th
On 28-Mar-16 21:05, Brad King wrote:
On 03/28/2016 01:49 AM, 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 re
On 03/28/2016 01:49 AM, 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 sophist
he 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
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_ATTRIB
25 matches
Mail list logo
