Re: [cmake-developers] daemon-mode meeting last Tuesday
Hello everyone, On Wed, Jun 29, 2016 at 12:41 AM, Stephen Kelly wrote: > Tobias Hunger wrote: > Name > > > Last year before publication I was calling this feature a 'metadata server' > (class called cmMetadataServer etc). I probably made a mistake renaming it > to a daemon. Now, 'metadata server' might be better and more specific than > 'server' alone. I do not care what we end up calling the baby, but considering that I do not expect more server modes to pop up in cmake (and considering that we do not yet fully know where we will end up with our little server), I think server is a fine name. > Change Notification > --- > > I wrote previously that I think change notification is an essential feature > of the first version of the protocol - otherwise the output is no better > than a static generated file. > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16589/focus=16648 > > Tobias was concerned that implementing filesystem watching for all necessary > platforms is an unreasonable burden and he would prefer something like > QFileSystemWatcher. > > libuv has a portable abstraction for filesystem change notification similar > in a way to QFileSystemWatcher. I implemented a basic use of the libuv API > fs notification API last year. > > Action item for me is to dig out that work or do it again. Then the metadata > server can emit a message on the protocol when the source directory content > changes. Creator will watch files itself. It has rather nice logic to save file descriptors when doing that. And since file descriptors are a scarce system resource I will need to turn file watching in server mode off. I do see a use-case where having the cmake server do the watching for its users. I am in no way opposed to doing that, but for me it is definitely not a feature required for the first version. > Feature Flags > - > >> 1.2 Protocol versions >> >> * We need the daemon-mode to support different protocol versions. >> >> * We want to have the option to mark protocol versions as experimental. > > As far as I know, Chrome has a development model whereby unfinished features > are checked into master immediately and developed there, instead of being > developed in a branch. The new/experimental features are disabled by default > with 'feature flags' so that people/CI can enable and test features which > are candidates to be enabled by default to everyone. > > We discussed whether this would make sense for the server instead of > 'experimental' protocol versions. We decided that such feature flags would > make sense if there would be many experimental features in flight from > multiple contributors over multiple cmake releases. We don't expect this to > be the case, so we consider feature flags to be over-engineered for the > server for now. Thanks for documenting that:-) I remembered that I had forgot to mention something we agreed on to not do, but I totally forgot what that was. > InReplyTo > - > > Tobias told me that the only reason for this is to make it easier for people > developing the actual protocol to paste blocks of text which contain > multiple server messages. For example a developer could paste a 'configure' > and a 'compute' and a 'codeModel' message over and over while implementing > the 'codeModel' message. If the 'configure' or 'compute' fail for some > reason with an error Tobias thinks it is confusing to figure out which one > had the error after the fact. I don't agree that that is hard or confusing. > > To be clear: The inReplyTo will never be used by client tools. It is only > for the above use-case. > > My concern is that if we add something only for a use-case like that, client > tools will start to use it for something it is not designed for. Then we > will regret that we did not design something better for the clients actual > need (because inReplyTo isn't exactly what they actually need). > > So, I am strongly in favor of keeping the protocol content to the absolute > minimum - only include things which we know client use-cases for. > Downstreams abusing CMake script APIs for things they were not intended for > is a long term problem for CMake. We should avoid introducing that problem > in the server protocol. > > Especially as inReplyTo, even in its current form is 'fuzzy' to me: Is it in > spontaneous messages which are not in response to anything (message() > output, change notifications etc)? Does it have 'special' values? "inReplyTo" is set in all messages generated by the server in reply to a request received by the client. If the server sends a signal that is not in reply to a request by the client (e.g. filesystem notification), then that will not have inReplyTo set. Considering that some requests trigger a whole lot of messages (e.g. "configure" triggers messages and progress notifications to be sent before the final reply), I find this field highly useful. > Initialization Granularity > ---
[cmake-developers] Patch for CM_OVERRIDE
Hello, I've attached a patch for the CM_OVERRIDE commit Best Regards Roman 0001-fixup-CM_OVERRIDE-Visual-Studio-2010-and-below-do-no.patch Description: Binary data -- 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] daemon-mode meeting last Tuesday
Tobias Hunger wrote: > Hello CMake Developers, > > Stephen Kelly and me met last Tuesday to talk about the daemon-mode patch > we both have been working on. It was a very productive meeting: We managed > to resolve almost all the differences of opinion we had. Thanks Tobias for the summary and everyone else for the discussion. Here are a few additional notes that I took when meeting Tobias last week. These notes don't change anything in the discussion, but expands on a few things to put some meat on the bones and lists some discarded design options. cmMessenger --- > * Having cmMessanger would be nice and will make things easier. In particular - a cmMessenger class can have some virtual methods implemented to print to the console as cmake::IssueMessage currently does. It would be inherited by a cmServerMessenger which would override the virtual methods to send them over the server IPC protocol instead of printing them on stdout. This has the advantage of not losing semantic information - a backtrace becomes a JSON array, meaning clients don't have to try to parse the backtrace out of the stdout message as they currently do. That becomes possible with just a IssueMessage virtual. See http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607 Additionally, the cmMessenger can have additional high-level virtual methods, such as for find_package results making it easier for user tools and IDEs to get a list of packages searched for and make it possible to give users use-case specific ways of specifying where packages are. Similarly it can have a virtual method for try_compile results (somehow - this might require extending the message type for scripting API) which also give user tools more opportunities to present the user with semantic information and not discard the intent of the person writing the buildsystem. Another place where a virtual method on cmMessenger would make sense is for policy warnings, giving user tools a chance to present them to the user without trying to parse them from stdout. There may be other messages which have semantics whose meaning we currently discard by printing to stdout. All of this is currently blocked by a clean-up in the parser needing further review and perhaps further implementation work: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=16663 Name Last year before publication I was calling this feature a 'metadata server' (class called cmMetadataServer etc). I probably made a mistake renaming it to a daemon. Now, 'metadata server' might be better and more specific than 'server' alone. Change Notification --- I wrote previously that I think change notification is an essential feature of the first version of the protocol - otherwise the output is no better than a static generated file. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16589/focus=16648 Tobias was concerned that implementing filesystem watching for all necessary platforms is an unreasonable burden and he would prefer something like QFileSystemWatcher. libuv has a portable abstraction for filesystem change notification similar in a way to QFileSystemWatcher. I implemented a basic use of the libuv API fs notification API last year. Action item for me is to dig out that work or do it again. Then the metadata server can emit a message on the protocol when the source directory content changes. Feature Flags - > 1.2 Protocol versions > > * We need the daemon-mode to support different protocol versions. > > * We want to have the option to mark protocol versions as experimental. As far as I know, Chrome has a development model whereby unfinished features are checked into master immediately and developed there, instead of being developed in a branch. The new/experimental features are disabled by default with 'feature flags' so that people/CI can enable and test features which are candidates to be enabled by default to everyone. We discussed whether this would make sense for the server instead of 'experimental' protocol versions. We decided that such feature flags would make sense if there would be many experimental features in flight from multiple contributors over multiple cmake releases. We don't expect this to be the case, so we consider feature flags to be over-engineered for the server for now. InReplyTo - > * Currently a reply (and error and all other messages in response to a > request) contain a "inReplyTo" with the type string from the request > triggering the reply. > > Stephen thinks that is not necessary and argues anything that is not > strictly necessary should not be in the first version of the protocol. Tobias told me that the only reason for this is to make it easier for people developing the actual protocol to paste blocks of text which contain multiple server messages. For example a developer could paste a 'config
[cmake-developers] Script to update liblzma from upstream.
Hi Brad,
I have attached a patch that adds a script to update liblzma from
upstream (closely modeled after the other update scripts). I am not
sure how these kinds of scripts need to be run.
We currently have a copy of liblzma version 5.0.5. The latest version
on the 5.0 branch is 5.0.8. Once the script is introduced, we may
consider switching to the 5.2 branch.
Cheers, Daniel
From c0401e6f56fe5c9c77e9a80a2c2ab063930f70ed Mon Sep 17 00:00:00 2001
From: Daniel Pfeifer
Date: Tue, 28 Jun 2016 23:10:11 +0200
Subject: [PATCH] Add script to update liblzma from upstream
---
Utilities/Scripts/update-liblzma.bash | 29 +
1 file changed, 29 insertions(+)
create mode 100755 Utilities/Scripts/update-liblzma.bash
diff --git a/Utilities/Scripts/update-liblzma.bash b/Utilities/Scripts/update-liblzma.bash
new file mode 100755
index 000..4933017
--- /dev/null
+++ b/Utilities/Scripts/update-liblzma.bash
@@ -0,0 +1,29 @@
+#!/usr/bin/env bash
+
+set -e
+set -x
+shopt -s dotglob
+
+readonly name="liblzma"
+readonly ownership="liblzma upstream "
+readonly subtree="Utilities/cmliblzma"
+readonly repo="http://git.tukaani.org/xz.git";
+readonly tag="v5.0"
+readonly shortlog=false
+readonly paths="
+ src/common/sysdefs.h
+ src/common/tuklib_integer.h
+ src/liblzma
+ COPYING
+"
+
+extract_source () {
+git_archive
+pushd "${extractdir}/${name}-reduced"
+mv src/common .
+mv src/liblzma .
+rmdir src
+popd
+}
+
+. "${BASH_SOURCE%/*}/update-third-party.bash"
--
2.9.0
--
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] [iOS] What is the correct way to add resources to an XCode project
No one? The target property RESOURCE does only allow files but no directories. Regards Roman > Am 22.06.2016 um 17:22 schrieb Roman Wüger : > > Hello, > > I read the mailing list but did find a way which works. > > At the moment I use Xcode 7.3.1 and CMake 3.5.2 which creates a project for > iOS 9.3. > > All I want is to add the directory "Images.xcassets" and a second directory > structure to be copied to the Resource folder listed in XCode. > > When I manually drag'n drop the directories into the Resource folder as > reference or as group everything is working. How can I archive this with > CMake? > > Thanks and regards > Roman > -- > > 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 -- 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] daemon-mode meeting last Tuesday
Hi Brad, Am 27.06.2016 7:18 nachm. schrieb "Brad King" : > I will take care of making libuv available within CMake's implementation > prior to merging the server mode work. See the "libuv in cmake" branch > of this thread. Perfect. Sorry, I only noticed the other thread after sending my mail. Best regards, Tobias -- 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
