Michael Scott wrote:
> If there are any problems with the proposed changes let me know.
Hi Michael,
Thanks for working on this topic over such a long time period to get it
right.
I closed
http://public.kitware.com/Bug/view.php?id=15677
and
http://public.kitware.com/Bug/view.php?id=14669
On 01/12/2016 01:18 PM, Michael Scott wrote:
> In this case I think there are no issues I'm aware of with the proposed
> changes.
Great, thanks. Applied and merged to 'next' for testing:
Add -Werror and -Wno-error command-line options
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=28f2d7
Most of that change appears to be just the number of spaces after a
period. I prefer two which is why the original message was that way.
Ah fair enough, I assumed the two spaces was a typo and was meant to be
just one space. Yes essentially the third patch just replaces the two
spaces with one
On 01/04/2016 06:52 PM, Michael Scott wrote:
> To round off the -W options functionality, I've implemented the -Werror
> and -Wno-error set of options for the two current types of messages, dev
> and deprecated. This includes updating the QT GUI to include new options
> for controlling this func
Hi Brad,
To round off the -W options functionality, I've implemented the -Werror
and -Wno-error set of options for the two current types of messages, dev
and deprecated. This includes updating the QT GUI to include new options
for controlling this functionality.
The third patch is not for ne
On 12/07/2015 01:51 PM, Michael Scott wrote:
>> I noticed one glitch. I built against Qt 5.5.1 on Linux and the
>> option dialog seems to truncate the labels.
> I think I've fixed it, by using vertical layouts rather than form
> layouts and setting the size policy to expanding for the widgets, if
I noticed one glitch. I built against Qt 5.5.1 on Linux and the
option dialog seems to truncate the labels.
I think I've fixed it, by using vertical layouts rather than form
layouts and setting the size policy to expanding for the widgets, if
that doesn't fix I'll need to look into QT in more d
On 12/06/2015 08:13 AM, Michael Scott wrote:
> Here are a couple of patches for adding in support for controlling the
> suppression of deprecated warning messages, in the cmake-gui.
Nice, thanks.
I noticed one glitch. I built against Qt 5.5.1 on Linux and the
option dialog seems to truncate the
Hi Brad,
Here are a couple of patches for adding in support for controlling the
suppression of deprecated warning messages, in the cmake-gui. Let me
know if there's any issues with the changes.
The first patch adds a new dialog window to control the suppression of
developer and deprecated wa
On 12/04/2015 10:52 AM, Michael Scott wrote:
>> Actually when one choose a build tree it will locate the corresponding
>> source tree automatically if both exist. Selecting the source tree
>> may be followed by creating a new build tree so that direction does
>> not happen automatically IIRC.
> Ok
Actually when one choose a build tree it will locate the corresponding
source tree automatically if both exist. Selecting the source tree
may be followed by creating a new build tree so that direction does
not happen automatically IIRC.
Okay, I'm not too familiar with the GUI, how do you choose a
On 12/04/2015 10:05 AM, Michael Scott wrote:
> The build tree is selected by changing the source directory setting in
> the GUI right?
Actually when one choose a build tree it will locate the corresponding
source tree automatically if both exist. Selecting the source tree
may be followed by crea
Let's start with the toggle because that will make cmake-gui able
to set the option just like the command line.
Sounds good, that's what I was thinking as well.
Also I'm not sure what to do about persistence of the option check
boxes in cmake-gui when selecting a different build tree. As a use
On 12/03/2015 05:56 PM, Michael Scott wrote:
>> Thanks. Applied with minor tweaks and merged to 'next' for testing:
>
> That's great, thanks. Now that the patches are in, would you say it's
> better to work on adding a deprecated toggle option to the cmake-gui, or
> to work on adding support fo
Thanks. Applied with minor tweaks and merged to 'next' for testing:
That's great, thanks. Now that the patches are in, would you say it's
better to work on adding a deprecated toggle option to the cmake-gui, or
to work on adding support for upgrading warnings to errors?
Cheers,
Michael
--
On 11/30/2015 02:16 PM, Michael Scott wrote:
> Great, I've changed the nullptr references to NULL instead.
Thanks. Applied with minor tweaks and merged to 'next' for testing:
Merge topic 'cmake-W-options' into next
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cfcc9d52
-Brad
--
Power
Great, I've changed the nullptr references to NULL instead.
Cheers,
Michael
>From 02016a44d1f6f571b96c54a0008c37e2e1fa3b7d Mon Sep 17 00:00:00 2001
From: Michael Scott
Date: Sun, 1 Nov 2015 16:05:15 +
Subject: [PATCH 1/8] Tests: Revise message in RunCMake.CommandLine -Wdev case
Use more pro
On 11/29/2015 08:48 AM, Michael Scott wrote:
> I've gone back and redone the patches with the suggestions you made
Thanks. This is in pretty good shape now I think. However, I see
use of `nullptr`. Please revise to use only C++98 constructs.
-Brad
--
Powered by www.kitware.com
Please keep
Hi Brad,
I've gone back and redone the patches with the suggestions you made,
hopefully they should be acceptable to apply now.
* The Help/release/dev/cmake-W-options.rst file is now modified as
part of the patches
* The method of enabling dev and deprecated warnings by default no
long
Hi Brad,
The hunk I included at the bottom of the message
Ah yeah, sorry missed that part in the message, I understand the change
that needs to be done now.
The current caching logic still needs some work
One idea that comes to mind, is to change it so that it doesn't enable
dev/deprecated
On 11/18/2015 02:41 AM, Michael Scott wrote:
>> I moved the hunk below forward to "Modify dev warning options to affect
>> deprecated warnings", the commit where it actually becomes needed
>> because the default changes.
> I'm not sure I follow, which hunk are we talking about here?
The hunk I inc
In particular,
I moved the hunk below forward to "Modify dev warning options to affect
deprecated warnings", the commit where it actually becomes needed
because the default changes.
I'm not sure I follow, which hunk are we talking about here?
Please add a Help/release/dev/cmake-W-options.rst fi
On 11/13/2015 04:51 PM, Michael Scott wrote:
> Here's the original patch split up into smaller more specific patches.
> Let me know if there's any issues or if everything's okay, so I can
> continue with the rest of the intended changes.
Thanks. That is much easier to review and see the purpose
Here's also a further patch for this set, to add the option to suppress
deprecated warning messages to the QT GUI. I'm not sure if it matters or
not about the "[PATCH 1/X]" in the patch's subject line, so I've
attached the other patches in the set again just with an updated count,
in case it do
Hi Brad,
Here's the original patch split up into smaller more specific patches.
Let me know if there's any issues or if everything's okay, so I can
continue with the rest of the intended changes.
Cheers,
Michael
From 48d8c38c7b5724e4b6b53fa8647046c96cec603b Mon Sep 17 00:00:00 2001
From: Mich
The goal of the old logic was to avoid populating the settings in the
cache if they are left as default. Instead you could check whether any
"dev" value has been set *after* parsing the options and if not then
set it to the default.
Ah okay I understand, that's no problem.
I've pretty much fin
On 11/06/2015 05:31 PM, Michael Scott wrote:
>> increments the count by default instead of only when an explicit
>> option has been set. Please revise accordingly based on the attached
>> state.
> I don't quite follow. Setting "dev" to DIAG_WARN in DiagLevels, before
> the users input is parsed (w
Thanks for the feedback.
Please split up the rest of the patch into a
series of steps like that
Okay I'll see if I can break it down further.
ignoreWarningLevels => force
Yes that does sound better, thanks.
increments the count by default instead of only when an explicit
option has been se
On 11/04/2015 06:40 PM, Michael Scott wrote:
> Here is the patch with all, new, error related code removed and
> including the relevant documentation changes.
Thanks. Now this is getting down closer to a reviewable scale.
However, this will be much easier to review as a series of small
increment
Okay fair enough.
Here is the patch with all, new, error related code removed and
including the relevant documentation changes.
Cheers,
Michael
From 2d6bb2c1ddd6854bc1f26f92893e9e8a745db08b Mon Sep 17 00:00:00 2001
From: Michael Scott
Date: Sun, 1 Nov 2015 16:05:15 +
Subject: [PATCH] Add
On 11/01/2015 11:09 AM, Michael Scott wrote:
> I've attached a version of the patch
Thanks.
> without the conversion
> functionality, for dev messages only, as the deprecated section wasn't
> part of this patch. I've also not included rst files in the commit, as
> it seems like a waste of time
The semantic challenges are in the warning=>error conversion so I'd like
to get the other parts reviewed and integrated first.
I've attached a version of the patch without the conversion
functionality, for dev messages only, as the deprecated section wasn't
part of this patch. I've also not incl
On 10/27/2015 06:59 PM, Michael Scott wrote:
> They were part of the original patch a while ago, so I left them in when
> I re-applied the proposed patch. Did you want to apply the changes piece
> by piece, or just the review the changes piece by piece? I can tailor
> the proposed patch(s) to su
that appear to be related to warning=>error upgrade options.
Didn't we just decide to not tackle this part yet?
They were part of the original patch a while ago, so I left them in when
I re-applied the proposed patch. Did you want to apply the changes piece
by piece, or just the review the cha
On 10/24/2015 04:46 AM, Michael Scott wrote:
> I've made the first set of changes, to reapply the series of previous
> changes for the -W options, along with some tweaks to improve the
> implementation and some additional tests for the changes.
Thanks. I see some hunks, including these:
> +``
Hi Brad,
Let's work out the command line options for the existing
deprecation warning/error options first and then extend capabilities as
a second step. It will be easier to review in smaller pieces anyway.
Okay no problem, I'll try and break the changes down into chunks for review.
I've made
On 10/21/2015 06:01 PM, Michael Scott wrote:
>> should defer this part until after the main warning control
>> command-line options are worked out.
> That sounds sensible, I'll make the proposed changes to the cmake and
> cmMessageCommand classes first, get some adequate tests in and then move
>
I think having local CMAKE_WARN_DEPRECATED/CMAKE_ERROR_DEPRECATED vars
can be left as specific to the message() command (and perhaps other
IssueMessage callers as deemed appropriate per-case). Otherwise we
should just have one global setting.
Okay that sounds good to me, makes the implementation
On 10/18/2015 07:59 AM, Michael Scott wrote:
> I was thinking of coming back to issue of the deprecation and author
> message options, now that CMake 3.4 has been released, is now a suitable
> time for it?
Yes. Early in the development cycle is best.
> We modify cmake::IssueMessage to check th
Hi Brad,
I was thinking of coming back to issue of the deprecation and author
message options, now that CMake 3.4 has been released, is now a suitable
time for it?
I was thinking of ideas and one came to mind, how does the following sound?
We modify cmake::IssueMessage to check the relevant
I'm going to proceed with my reversion of the entire feature for 3.4.
We can pick this up during post-3.4 development when you have time.
Then we can review the all related semantics together.
Okay, that's fair enough, sorry it hasn't been possible to get it into
the 3.4 release in time.
Chee
On 09/25/2015 04:12 PM, Brad King wrote:
> I'm going to proceed with my reversion of the entire feature for 3.4.
> We can pick this up during post-3.4 development when you have time.
> Then we can review the all related semantics together.
Reverted here:
Revert topic 'cmake-W-options'
http://cm
On 09/25/2015 03:44 PM, Michael Scott wrote:
> it's release period at my office too so a busy time there as well.
Okay, I really don't want to try to rush in a fix for this before the
3.4 deadline, especially when we're both busy with other things. The
entire feature was developed under the misco
Sorry I'm being a bit slow with this topic, it's release period at my
office too :D so a busy time there as well.
The cmake::Configure check for that runs before the scripts run so
it is not possible to get script-provided values there. Do you have
a check in a new context that occurs later?
On 09/24/2015 05:45 PM, Michael Scott wrote:
> I've created a fix for the issue of -Wno-dev and -Wno-deprecated options
> not being honoured, and extended the tests to cover this additional
> scenario.
Thanks for working on it.
> However I'm having an issue with determining if variables are set
I've created a fix for the issue of -Wno-dev and -Wno-deprecated options
not being honoured, and extended the tests to cover this additional
scenario.
However I'm having an issue with determining if variables are set in
cmake.cxx. The initial fix checked for the variables using the
"GetCacheE
On 09/22/2015 08:53 AM, Brad King wrote:
> In this case we have a bug in a new feature that was
> introduced in post-3.3 development so we need to either fix it or
> remove the offending parts of the new features before Oct 1 for 3.4.
In preparation for the 3.4 freeze I've added a topic to revert
On 09/21/2015 05:51 PM, Michael Scott wrote:
> Yes the -Werr-dev, -Wno-err-dev, -Werr-deprectated and
> -Wno-err-deprecated may be trickier than expected to get behaving as
> intended. I'll try and get a better idea of the users of IssueMessage
> and see if some ideas come to mind. Removing them
The -Wdev/-Wno-dev options have always been for all messages
output by any part of CMake. This needs to be preserved/corrected.
Okay, I've fixed the change to cmake::PrintMessagePreamble, so that
it'll stop warning or error dev or deprecated messages getting printed
out when the relevant CMake
On 09/19/2015 06:32 PM, Michael Scott wrote:
> whether the -W options are intended to only be applicable
> for the message command (and so the current behaviour is correct),
> or whether they should affect all author and deprecated messages
> output by other parts of CMake?
The -Wdev/-Wno-dev opti
Investigating the issue a bit more, I can see why it's happening for the
given example. When I made those changes, I only modified the "message"
CMake command, to check the CMAKE_WARN/ERROR_DEPRECATED and
CMAKE_SUPPRESS_DEVELOPER_WARNINGS variables before outputting the
message. The message com
On 17/09/2015 13:49, Brad King wrote:
This caused a regression:
-Wno-dev doesn't work any more in CMake 3.4
http://www.cmake.org/Bug/view.php?id=15747
Please take a look to fix it and extend the test suite accordingly.
Thanks,
-Brad
Ah okay, I've replicated it on my Linux development env
On 07/29/2015 09:26 AM, Brad King wrote:
> cmake: Add -W options to control deprecation warnings and errors
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c96fe0b4
This caused a regression:
-Wno-dev doesn't work any more in CMake 3.4
http://www.cmake.org/Bug/view.php?id=15747
Please ta
Brad King wrote:
> On 08/01/2015 04:03 AM, Stephen Kelly wrote:
>> I still think it's a bit odd that policies and message(DEPRECATED) use a
>> different semantic though (ie, message(DEPRECATED) should issue a warning
>> by default unless -Wno-dev is used).
>
> ...or -Wno-deprecated
>
> That sema
On 08/03/2015 09:43 AM, Domen Vrankar wrote:
> Since CPack only gets CPACK_* variables from CMake we can't use
> CMAKE_SUPPRESS_DEVELOPER_ERRORS to revert back to warnings.
The mistake is that message() now treats warnings as errors
unless explicitly suppressed. While normal CMake runs suppress
i
> The branch seems to make the RunCMake.CPack_RPM test fail on my machine. I
> have not investigated.
Missed this thread... I was talking to Brad about this.
Failing test is written exactly for testing author warning message
(CPackRPM.cmake:560). RPM packages may be relocatable but if
relocation p
Brad King wrote:
> On 07/27/2015 07:07 PM, Michael Scott wrote:
>> I've changed the -W dev options to affect the deprecated warnings/errors
>> as well, but only if the user hasn't used one of the options that
>> control deprecated warnings (-Wdeprecated, -Wno-deprecated,
>> -Werror=deprecated, -Wn
On 07/27/2015 07:07 PM, Michael Scott wrote:
> I've changed the -W dev options to affect the deprecated warnings/errors
> as well, but only if the user hasn't used one of the options that
> control deprecated warnings (-Wdeprecated, -Wno-deprecated,
> -Werror=deprecated, -Wno-error=deprecated),
Hi,
After the last feedback, I've made some changes which should address the
points that were talked about.
I've changed the -W dev options to affect the deprecated warnings/errors
as well, but only if the user hasn't used one of the options that
control deprecated warnings (-Wdeprecated, -W
On 07/15/2015 05:08 PM, Michael Scott wrote:
> Looking at the cmMessageCommand::InitialPass and
> cmake::PrintMessagePreamble code, if we want to mirror the deprecation
> message behaviour, I'm tempted to suggest we also modify the message
> mode "AUTHOR_WARNING" to be "AUTHOR" instead. It would
Looking at the cmMessageCommand::InitialPass and
cmake::PrintMessagePreamble code, if we want to mirror the deprecation
message behaviour, I'm tempted to suggest we also modify the message
mode "AUTHOR_WARNING" to be "AUTHOR" instead. It would make the mode
clearer on it's new behaviour and all
On 07/08/2015 04:01 PM, Michael Scott wrote:
> Making dev influence deprecation variables is not a problem. To support
> -Werror=dev we'll need a new variable I'm thinking though, something
> like a boolean CMAKE_SUPPRESS_DEVELOPER_ERRORS?
Yes, thanks.
> What should be the expected behaviour wh
Since AUTHOR_WARNING is a superset of DEPRECATION_WARNING I think
-W[no-]dev can influence CMAKE_WARN_DEPRECATED. Please also add
-W[no-]error=dev to turn AUTHOR_WARNING into an error and also make
it influence CMAKE_ERROR_DEPRECATED. Then -Wdeprecated and friends
can still be used to control th
On 07/02/2015 04:45 PM, Michael Scott wrote:
> On 06/30/2015 05:42 PM, Stephen Kelly wrote:
>> What is the difference between the intended uses of those existing options
>> and the intended uses of the new options, given that -Wno-dev is mostly
>> useful for third parties to silence policy warnings
Sorry, I've added in the missing method to cmake.cxx, which updates the
WarningLevel map according to the boolean provided. cmake-gui compiles
without errors again.
I could add support for the new options to the GUI, in which case I
would probably also go back to the changes I made to cmake.cx
What is the difference between the intended uses of those existing options
and the intended uses of the new options, given that -Wno-dev is mostly
useful for third parties to silence policy warnings?
Working on this issue, I did find the different variables/options a bit
confusing. dev and depr
Michael Scott wrote:
> Thanks for the comments, here is the previous patch, with the suggested
> amendments.
Thanks for working on this.
I'm wondering how these new command line options relate to the existing
options -Wdev and -Wno-dev. Is there any reason not to make those existing
options se
On 06/24/2015 05:30 PM, Michael Scott wrote:
> Thanks for the comments, here is the previous patch, with the suggested
> amendments.
Thanks.
This hunk:
> - void SetSuppressDevWarnings(bool v)
> -{
> - this->SuppressDevWarnings = v;
> - this->DoSuppressDevWarnings = true;
> -}
Thanks for the comments, here is the previous patch, with the suggested
amendments.
Cheers,
Michael
On 24/06/2015 15:45, Brad King wrote:
On 06/23/2015 03:57 PM, Michael Scott wrote:
I've implemented some changes to cmake.cxx and cmake.h, to implement
setting the CMAKE_ERROR_DEPRECATED and CM
On 06/23/2015 03:57 PM, Michael Scott wrote:
> I've implemented some changes to cmake.cxx and cmake.h, to implement
> setting the CMAKE_ERROR_DEPRECATED and CMAKE_WARN_DEPRECATED variables
> via command line options, for the Mantis issue 0014669, in a generic GCC
> style pattern. I've taken on b
Hi,
I've implemented some changes to cmake.cxx and cmake.h, to implement
setting the CMAKE_ERROR_DEPRECATED and CMAKE_WARN_DEPRECATED variables
via command line options, for the Mantis issue 0014669, in a generic GCC
style pattern. I've taken on board the previous suggestions, including
addin
On 06/22/2015 03:56 PM, Michael Scott wrote:
> the actual and expected values are identical. Why would this happen?
The expected value file is actually a regular expression that must
match the actual value. This allows it to tolerate path differences
and other minor variations in the actual outpu
Hi Brad,
Apologies for taking a little while with this. I've addressed those
points and added all the tests I think are appropriate for this, however
when I run one of them it fails because stderr is not as expected, but
the actual and expected values are identical. Why would this happen?
Te
On 06/13/2015 01:41 PM, Michael Scott wrote:
> I've implemented some changes to cmake.cxx and cmake.h, to implement
> setting the CMAKE_ERROR_DEPRECATED and CMAKE_WARN_DEPRECATED variables
> via command line options, for the Mantis issue 0014669, in a generic GCC
> style pattern. I've attached t
Hi,
I've implemented some changes to cmake.cxx and cmake.h, to implement
setting the CMAKE_ERROR_DEPRECATED and CMAKE_WARN_DEPRECATED variables
via command line options, for the Mantis issue 0014669, in a generic GCC
style pattern. I've attached the proposed patch to this email, does this
loo
75 matches
Mail list logo
