Hi,
I'm looking to do a bit more CMake development and the CMake server
project looks interesting. Does this area still need more contributors
and what's the best way to see what tasks there are?
Thanks,
Michael
--
Powered by www.kitware.com
Please keep messages on-topic and check the
Yes. Did you have a close look at the commits? I'm not really sure they are
correct, and I wonder if you have any thoughts on the first one which
discusses interface?
I went back and had a closer look at the major changes. I think on the
whole the cmMessenger class is good and a clear
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
that future users of the above functionality should
also do this check, which doesn't sound like a good idea to me. What
are your thoughts on this last point?
Cheers,
Michael
>From 319afb022cae89d64bc9075e2a686966971cda1c Mon Sep 17 00:00:00 2001
From: Michael Scott <michael.scott...@gma
depth as I've not got
much experience with it. Which Linux distro did you notice it in, looks
like gnome3?
Patches for the fix are attached.
Cheers,
Michael
>From 320d791eb6f97e590716c555da0345de31e65cfc Mon Sep 17 00:00:00 2001
From: Michael Scott <michael.scott...@gmail.com>
Date: S
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
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
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
--
Great, I've changed the nullptr references to NULL instead.
Cheers,
Michael
>From 02016a44d1f6f571b96c54a0008c37e2e1fa3b7d Mon Sep 17 00:00:00 2001
From: Michael Scott <michael.scott...@gmail.com>
Date: Sun, 1 Nov 2015 16:05:15 +
Subject: [PATCH 1/8] Tests: Revis
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
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
,
in case it does matter.
Cheers,
Michael
>From cc16db0e2c818714034e2948a0b3b16b7774252f Mon Sep 17 00:00:00 2001
From: Michael Scott <michael.scott...@gmail.com>
Date: Sun, 15 Nov 2015 17:47:12 +
Subject: [PATCH 8/8] GUI option for deprecated warning messages suppression.
Add an opti
: Michael Scott <michael.scott...@gmail.com>
Date: Sun, 1 Nov 2015 16:05:15 +
Subject: [PATCH 1/7] Tests: Revise message in RunCMake.CommandLine -Wdev case
Use more prose-like capitalization.
---
Tests/RunCMake/CommandLine/Wdev-stderr.txt | 2 +-
Tests/RunCMake/CommandLine/Wdev.cmake
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
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
any issues with this first chunk please let me know.
Cheers,
Michael
From 14ab5c6e0c46fc60ed9007fa06ce9b3c135e3150 Mon Sep 17 00:00:00 2001
From: Michael Scott <michael.scott...@gmail.com>
Date: Sun, 1 Nov 2015 16:05:15 +
Subject: [PATCH] Add -W options to control deprecation and author
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
, in the IssueMessage function, and update the callers of
the function to check the error flag and take appropriate action.
Cheers,
Michael
From 8d7aae1411331b980bd5d7515e5f7326db5890cb Mon Sep 17 00:00:00 2001
From: Michael Scott <michael.scott...@gmail.com>
Date: Fri, 23 Oct 2015 19:48:58
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
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.
in the cache?
This change causes the RunCMake.message and RunCMake.ObsoleteQtMacros
tests for fail, as they do what is described just above.
Cheers,
Michael
From 9096cd7f2a0ff42db88c4adb25a403e75e381756 Mon Sep 17 00:00:00 2001
From: Michael Scott <michael.scott...@gmail.com>
Date: Tue,
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
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
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
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
Hi,
I'm planning on having a look at the CMake issue "Allow ALIAS of
IMPORTED targets", 0015569. After reading the thread between yourself
and Marc, I wanted to ask a couple of things before I start going
further with it.
The proposed change would be for the add_library and add_executable
using the
provided ZLIB_LIBRARY variable (if the library was found).
Cheers,
Michael
From c7905e97fa0a1412a1b05ee295d4bfa97c699b3e Mon Sep 17 00:00:00 2001
From: Michael Scott <michael.scott...@gmail.com>
Date: Tue, 1 Sep 2015 20:41:27 +0100
Subject: [PATCH] Support finding the debug and r
configurations when the corresponding library is found, and not set the
generic IMPORTED_LOCATION property at all.
Cheers,
Michael
From ef53d82356062a1e7babafaa588cb34832b491fc Mon Sep 17 00:00:00 2001
From: Michael Scott michael.scott...@gmail.com
Date: Sun, 23 Aug 2015 10:45:27 +0100
Subject
Please add each of the _DEBUG and _RELEASE configurations if and
only if the corresponding variables are set. Grep for mention of
IMPORTED_CONFIGURATIONS in other Modules/Find*.cmake files for
examples.
I'm assuming that there should be a IMPORTED_LOCATION property defined
in all cases as
9d1aa288cc68008797cbf67d0fe86a8713b4ad29 Mon Sep 17 00:00:00 2001
From: Michael Scott michael.scott...@gmail.com
Date: Sun, 23 Aug 2015 10:45:27 +0100
Subject: [PATCH] Find the debug and release variants as separate libraries,
providing both in ZLIB_LIBRARIES and ZLIB::ZLIB's imported location
properties, when
and release variants, to be consistent with other
Find modules. Let me know if this shouldn't be done in this situation.
Cheers,
Michael
From 92e2d4933d57305fb1b9343c16b68d36c1a29c09 Mon Sep 17 00:00:00 2001
From: Michael Scott michael.scott...@gmail.com
Date: Sun, 23 Aug 2015 10:45:27 +0100
Subject
to the QT GUI to allow it to use these
changes, but I thought it'd be best to commit the given changes now, and
then do a separate chunk of work for the QT GUI changes, as the changes
for all this have grown larger than expected.
Cheers,
Michael Scott
From 3ed09142ec81861670ca2fe27e28ca782ad60e9f Mon
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 allow
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
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
to cmake.cxx and make
the code related to WarningLevel a bit more generic and replace
instances of dev and deprecated with constants to make the changes a
bit more maintainable.
Cheers,
Michael
On 25/06/2015 15:50, Brad King wrote:
On 06/24/2015 05:30 PM, Michael Scott wrote:
Thanks for the comments
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
adding tests for the new options and updating the cmake application
options documentation. I've attached the proposed patch to this email,
please let me know if there are any incorrect changes in the patch.
Michael Scott
From 2fc8c47ff2112a1f28d4f3c8513e29c94ecb6a9d Mon Sep 17 00:00:00 2001
From
.//
// actual-err CMake Error: Problem processing arguments. Aborting./
Cheers,
Michael
On 15/06/2015 15:06, Brad King wrote:
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
this
look like a sensible implementation?
Michael Scott
From ae4f9a42ff5e8d3156010287d013099e75c0cde4 Mon Sep 17 00:00:00 2001
From: Michael Scott michael.scott...@gmail.com
Date: Sat, 13 Jun 2015 18:34:31 +0100
Subject: [PATCH] Refactored the -Wdev and -Wno-dev to use a generic -W parser,
which follows
Hi,
I've done some work on the commands documentation, generally adding more
RST markup, as part of the Mantis issue 0015587. I've attached the
proposed patch to this email, please let me know if there are any
incorrect changes to the documentation in the patch.
Michael Scott
From
Hi Brad,
Thanks! Initially I'd be looking for suggestions for entry tasks, then
perhaps after some of those, if I see an area I'm particularly
interested in I could propose contributions to those areas.
Cheers,
Michael
On 26/05/2015 14:34, Brad King wrote:
On 05/25/2015 12:20 PM, Michael
of CMake, so I'd like
to find out more about what opportunities there are for this, and how
I'd go about doing it?
Cheers,
Michael Scott
--
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
44 matches
Mail list logo
