Re: [cmake-developers] daemon-mode meeting last Tuesday
Hi Rolf, Am 23.06.2016 23:00 schrieb "Rolf Eike Beer" : > What about just passing --server-fd= into it? That way the client can set > up whatever if wants to pass there and CMake has nothing to do with any setup. > And if one really wants to get messy one could pass a tty there. Not sure whether that is even possible on all platforms we need. Libuv (which the server is using) apparently has a cross-platform solution for setting up a communication channel like the one we need, so I want to give that a try. 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
Re: [cmake-developers] daemon-mode meeting last Tuesday
Hi Ben, Am 23.06.2016 22:48 schrieb "Ben Boeckel" : > cmake-oracle sounds reasonable for what it's doing to me. I hope this thing will provide information more reliable than e.g. the Oracle of Delphi in ancient Greece:-) 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
Re: [cmake-developers] daemon-mode meeting last Tuesday
Am 23.06.2016 22:46 schrieb "Brad King" : > > On 06/23/2016 08:27 AM, Tobias Hunger wrote: > Great! Thanks for the detailed summary of the meeting and status of the design. You are welcome. > > * Some names could be improved. Suggestions welcome. > > We'll cover these in more detail during review. The most important name is > the name of the feature, and IMO "daemon" is not an accurate description of > it (it is never re-parented to 'init' and has a lifetime tied to the client). > I think "server" would be better but am open to other suggestions. Even if > it later really becomes a daemon the name "server" will still be appropriate. I'll create a task to rename it to "server" then. > > * 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. > > > > I like having this as it makes it helps to identify what a reply/error is > > related to. I often paste a whole string of requests into the daemon and > > if there is an error it is really easy to see how for things got. > > Would each type of query have a known type of response? Shouldn't the response > objects have a type too? It has a type: "reply" (or "error"). I so far use the inReplyTo field to specify what the request a reply refers to. Stephen thinks that is not necessary as there is always one request in flight and the client can just figure things out without additional information. > Also, doesn't the cookie allow the query/response > pairs to be matched? In theory yes. But a protocol should work without having to reply on cookies. A cookie is user data attached to an request. The idea is that e.g. an IDE can run a request for some more details on some node in the project tree view and pass some form of ID of the node the information is for along with the query. That can simplify client code a lot. > > * Should we have a split between header (cookie/type/inReplyTo) and data? > > > > Stephen suggested passing all data that is from/for the client in a > > "body" attribute to make messages more uniform. > > > > I think that is just adding one more level into the JSON file for no > > real benefit. > > I agree with Tobias that there is no reason to put the body fields in > a sub-object. However, I think the header fields should go in a sub-object > named by a "header" field. That will isolate the header field names from > the body fields (good for sorted views, future addition of headers, etc.). The header currently is the type, inReplyTo and the cookie. I did not see the need to separate those. > > * This is currently used to set sourcedirectory, builddirectory and > > generator. > > > > These three should be passed in via the command line instead, again > > to avoid trouble with users switching to different build directories/etc. > > while the daemon is running, which might trigger problems with state > > cleanup, etc. > > Currently cmake-gui supports switching generators, build trees, etc., so > there is some precedent for such switching within a single process. If > we have (re-)initialization bugs they should simply be fixed. So you think we should keep that? I do not have an opinion here and need to follow the advise of people more knowledgeable about CMake code than I am. > > * Figure out whether a PDB file is actually going to be build. Currently > > the PDB file is added to the list of artifacts whenever there is a .lib > > file, which is probably wrong. Brad: Do you have an idea how to > > get this information? > > I'm not sure we have that information. IIRC CMake only adds settings to the > generated build system to tell the tools where to put the .pdb and what to > call it if it happens to be created. We don't have install rules for them > so there has never been a need to know whether they will actually be created. > Perhaps our format for the list of artifacts needs a way to indicate whether > an artifact is optionally present. I think CMake should know what is generated and should not leave decisions like that up to generators. > > 2.8 buildsystem (return cmake files) > > > > * Return a list of cmake files (CMakeLists.txt, etc.) in different categories > > (in source directory/in build directory/in the system). > > > > * Stephen suggested to rename this to "cmake_rerun_depends". I am not sure > > that name is much better than what is currently used. > > "cmake_rerun_depends" describes the current use case for these. I don't think > the name "buildsystem" is clear though. Other ideas: > > * cmake_files > * cmake_inputs > * input_files I like "cmakeInputs":-) I'll make a task to change it if nobody opposes this suggestion. Best Regards, Tobias -- Powe
Re: [cmake-developers] daemon-mode: Infrastructure
On Tue, Jun 14, 2016 at 02:00:14 +0200, Tobias Hunger wrote:
> Implementing new Protocol Versions:
> ==
> Deprecating old Protocol Versions:
>
One idea that came up on a previous project was the following:
namespace protocol {
namespace aspect1 {
namespace v1 {
}
namespace v2 {
}
}
namespace aspect2 {
namespace v1 {
}
}
namespace v1 {
namespace aspect1 = aspect1::v1;
namespace aspect2 = aspect1::v1;
Version version(1, 0);
bool deprecated = true;
}
namespace v2 {
namespace aspect1 = aspect1::v2;
namespace aspect2 = aspect1::v1;
Version version(2, 0);
bool deprecated = false;
}
namespace latest = v2;
}
Then the code can use `protocol::v1::aspect1::` for explicit v1
communication and `protocol::latest::` in any normal code. It does
require C++11 though. There's probably some template metaprogramming
magic that could be done to instantiate communication ends for each
protocol namespace once communication is done.
I have no idea how maintainable in the long-term this is though.
--Ben
--
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
> 1.1 Communication: > > * Clients should talk to daemon mode via a socket (libuv supports that), > but we also want to support stdin/stdout at least for a "debug mode" * > There should be a separate command line switch to start stdin/out mode and > for socket mode > * This is needed before it makes sense to merge the patch set. What about just passing --server-fd= into it? That way the client can set up whatever if wants to pass there and CMake has nothing to do with any setup. And if one really wants to get messy one could pass a tty there. Eike signature.asc Description: This is a digitally signed message part. -- 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
On Thu, Jun 23, 2016 at 16:46:48 -0400, Brad King wrote: > On 06/23/2016 08:27 AM, Tobias Hunger wrote: > > * Figure out whether a PDB file is actually going to be build. Currently > > the PDB file is added to the list of artifacts whenever there is a .lib > > file, which is probably wrong. Brad: Do you have an idea how to > > get this information? > > I'm not sure we have that information. IIRC CMake only adds settings to the > generated build system to tell the tools where to put the .pdb and what to > call it if it happens to be created. We don't have install rules for them > so there has never been a need to know whether they will actually be created. > Perhaps our format for the list of artifacts needs a way to indicate whether > an artifact is optionally present. Well, there is this issue: https://gitlab.kitware.com/cmake/cmake/issues/10636 which requests that they always be generated :) . > > 2.8 buildsystem (return cmake files) > > > > * Return a list of cmake files (CMakeLists.txt, etc.) in different > > categories > > (in source directory/in build directory/in the system). > > > > * Stephen suggested to rename this to "cmake_rerun_depends". I am not sure > > that name is much better than what is currently used. > > "cmake_rerun_depends" describes the current use case for these. I don't think > the name "buildsystem" is clear though. Other ideas: > > * cmake_files > * cmake_inputs > * input_files Also possible: regen_trigger_files --Ben -- 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
On Thu, Jun 23, 2016 at 16:46:48 -0400, Brad King wrote: > On 06/23/2016 08:27 AM, Tobias Hunger wrote: > > * Some names could be improved. Suggestions welcome. > > We'll cover these in more detail during review. The most important name is > the name of the feature, and IMO "daemon" is not an accurate description of > it (it is never re-parented to 'init' and has a lifetime tied to the client). > I think "server" would be better but am open to other suggestions. Even if > it later really becomes a daemon the name "server" will still be appropriate. > > As you said before there has been a lot of PR with the name "daemon", but I > don't think it is too late to change it. Those interested in the features > will see the new name when it appears in release notes and should easily be > able to recognize it. cmake-oracle sounds reasonable for what it's doing to me. --Ben -- 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
On 06/23/2016 08:27 AM, Tobias Hunger wrote: > 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. Great! Thanks for the detailed summary of the meeting and status of the design. > * Some names could be improved. Suggestions welcome. We'll cover these in more detail during review. The most important name is the name of the feature, and IMO "daemon" is not an accurate description of it (it is never re-parented to 'init' and has a lifetime tied to the client). I think "server" would be better but am open to other suggestions. Even if it later really becomes a daemon the name "server" will still be appropriate. As you said before there has been a lot of PR with the name "daemon", but I don't think it is too late to change it. Those interested in the features will see the new name when it appears in release notes and should easily be able to recognize it. > * Clients should talk to daemon mode via a socket (libuv supports that), > but we also want to support stdin/stdout at least for a "debug mode" > * There should be a separate command line switch to start stdin/out mode >and for socket mode > * This is needed before it makes sense to merge the patch set. Given the noise we have on stdout it makes sense to offer a dedicated communication path for clients. > * 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. > > I like having this as it makes it helps to identify what a reply/error is > related to. I often paste a whole string of requests into the daemon and > if there is an error it is really easy to see how for things got. Would each type of query have a known type of response? Shouldn't the response objects have a type too? Also, doesn't the cookie allow the query/response pairs to be matched? > * Should we have a split between header (cookie/type/inReplyTo) and data? > > Stephen suggested passing all data that is from/for the client in a > "body" attribute to make messages more uniform. > > I think that is just adding one more level into the JSON file for no > real benefit. I agree with Tobias that there is no reason to put the body fields in a sub-object. However, I think the header fields should go in a sub-object named by a "header" field. That will isolate the header field names from the body fields (good for sorted views, future addition of headers, etc.). > * This is currently used to set sourcedirectory, builddirectory and > generator. > > These three should be passed in via the command line instead, again > to avoid trouble with users switching to different build directories/etc. > while the daemon is running, which might trigger problems with state > cleanup, etc. Currently cmake-gui supports switching generators, build trees, etc., so there is some precedent for such switching within a single process. If we have (re-)initialization bugs they should simply be fixed. > * Figure out whether a PDB file is actually going to be build. Currently > the PDB file is added to the list of artifacts whenever there is a .lib > file, which is probably wrong. Brad: Do you have an idea how to > get this information? I'm not sure we have that information. IIRC CMake only adds settings to the generated build system to tell the tools where to put the .pdb and what to call it if it happens to be created. We don't have install rules for them so there has never been a need to know whether they will actually be created. Perhaps our format for the list of artifacts needs a way to indicate whether an artifact is optionally present. > 2.8 buildsystem (return cmake files) > > * Return a list of cmake files (CMakeLists.txt, etc.) in different > categories > (in source directory/in build directory/in the system). > > * Stephen suggested to rename this to "cmake_rerun_depends". I am not sure > that name is much better than what is currently used. "cmake_rerun_depends" describes the current use case for these. I don't think the name "buildsystem" is clear though. Other ideas: * cmake_files * cmake_inputs * input_files -Brad -- 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/hel
Re: [cmake-developers] [PATCH] Update documentation for VERSION and SOVERSION for Mach-O file formats (OSX, iOS, BSD etc.)
On 06/23/2016 11:50 AM, Bartosz Kosiorek wrote: > how to set "current version" and "compatibility version" on > binaries produced by OS X. > I have updated documentation to describe how to archieve that Thanks. I revised the changes a bit and applied the patch: Help: Describe VERSION and SOVERSION meanings for Mach-O binaries https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=00caa1dd > Do you think it could be pushed into CMake 3.6 ? Yes, since it is a documentation-only update. I've queued it for merge to 'release'. -Brad -- 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] [MODERN] CMake 3.6+ vs Qt 5.7 vs MSVC2015
Hi all! Modern master updated! :-) It's time to upgrade: CMake 3.6.20160623 and CMake 3.6.0-rc3 now available! Let me remind you of the link. Windows 32bit: http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe http://ifw.podsvirov.pro/cmake/files/v3.6/cmake-3.6.0-rc3-win32-x86.exe Windows 64bit: http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe http://ifw.podsvirov.pro/cmake/files/v3.6/cmake-3.6.0-rc3-win64-x64.exe If you have used it before, you can update via "CMake Maintenance Tool" I used Windows 7, but it should work for Windows Vista and Windows 8 and Windows 10. I ask those wishing to test the functionality. Please test it :-) >>> 01.10.2015, 09:29, Konstantin Podsvirov" : Hi all! Modern master alive! :-) It's been almost a month and it's time to upgrade: 3.3.20150901 CMake => CMake 3.3.20151001 Dear friends, I have a question and call for help. With my assistance the project has an option for component installation project: CMake_INSTALL_COMPONENTS Unfortunately not all files found your component. The files to be installed without specifying a component fall into 'Unspecified' component. Need to parse them out and assign them to the component context. Now have the components: - cmake; - ctest; - cpack; - cmake-gui; - sphinx-man; - sphinx-html; - sphinx singlehtml; - sphinx-qthelp and General for everything else Is Unspecified; A list of unaccounted for 'Unspecified' of files to install on the Window is attached. Links to the installers were specified earlier (see below). On 28.07.2015, 17:49, "Konstantin Podsvirov" : > Hi dear CMake developers! > > 27.07.2015, 18:52, "Brad King" : >> On 07/24/2015 03:46 AM, Konstantin Podsvirov wrote: >>> To solve the problem you run cmake-gui is now possible with the >>> the following changes: >> >> Applied as two separate commits with minor tweaks: >> >> cmake-gui: Install Qt5 Windows platform plugin >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42f0155b >> >> CMake: Add option CMake_INSTALL_DEPENDENCIES >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=068e7962 > > Code now in 'master' branch. > > Thanks, Brad! > > Meet/install/CMake built modern update on MSVC2015 c QtDialog based on > Qt 5.5 from today :-) > > Windows 32bit: > > http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe > > Windows 64bit: > > http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe > > cmake-gui should work now, but if not, then update your system and > install > > The Visual C++ Redistributable for Visual Studio 2015 from the link > below: > > http://www.microsoft.com/en-us/download/details.aspx?id=48145 > > As always, questions and suggestions are welcome. -- Regards, Konstantin Podsvirov ,-- 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 >>> >>> Regards, >>> Konstantin Podsvirov > > Regards, > Konstantin Podsvirov > -- > > 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 Regards, Konstantin Podsvirov -- 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,
[cmake-developers] [PATCH] Update documentation for VERSION and SOVERSION for Mach-O file formats (OSX, iOS, BSD etc.)
Hello. Last time I faced problem, how to set "current version" and "compatibility version" on binaries produced by OS X. I have updated documentation to describe how to archieve that, to make life easier for new CMake users. Please let me know what do you think about it. Do you think it could be pushed into CMake 3.6 ? Best Regards Bartosz 0001-Add-description-of-versions-target-property-for-Mach.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] patch for FindProtobuf.cmake
On 06/22/2016 08:08 PM, Miroslav Drahos wrote:
> I believe I found a bug in FindProtobuf.cmake. Using set with two
> parameters will insert an unwanted semicolon, the list separator.
> The changes I made are like this (several occurrences):
>
> -set(_protobuf_include_path -I ${CMAKE_CURRENT_SOURCE_DIR})
> +set(_protobuf_include_path "-I${CMAKE_CURRENT_SOURCE_DIR}")
The ";" in the value of the _protobuf_include_path are just normal
list separators which will be used to divide the list when the variable
is later referenced as ${_protobuf_include_path} in add_custom_command
calls. The difference that this patch makes is `-I foo` v. `-Ifoo` on
the resulting command lines.
> I also added a test for FindProtobuf.cmake, which is a new addition.
> The complete patch is attached. What I cannot figure out is how to
> run the test? When I configure cmake build, I don’t see an option
> to set the path to protobuf.
Thanks for writing a test! The `CMake_TEST_Find...` options are all
undocumented options that have to be added explicitly to the cache
when configuring (e.g. -DCMake_TEST_FindProtobuf=1). The problem is
that we don't know what packages are installed on a system such that
running a find module test for them will work. Therefore we just
keep them off by default and enable the tests on nightly testing
machines where they are expected to work. I'd like to find a better
solution but this is at least better than when we had no tests for
individual find modules at all.
Currently the patch makes the test get added as part of the build
of CMake itself. Please see the other Tests/Find* directories for
how the tests should be laid out.
Thanks,
-Brad
--
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] handling components in Find****
On 06/22/2016 08:11 AM, Farbos a wrote: > I am trying to write a Find module with components and I am not sure > of how it should be written. > I attached the find module, Could someone tell me if I did it well? It looks okay to me from a quick glance. Side note: For variables private to the module I suggest using a prefix like `_IlmBase_` to make it clear to readers that they are not for public use. Are there any dependencies between components? If so then things need to be more complicated, especially to provide the imported targets. See FindBoost for an example. -Brad -- 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
[cmake-developers] daemon-mode meeting last Tuesday
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. Here is a short summary of what we talked about: 0) General * We both want a daemon mode:-) * Some names could be improved. Suggestions welcome. * Having cmMessanger would be nice and will make things easier. * We agreed that we should get the basic infrastructure part reviewed first, followed by the functionality up to the project structure (codemodel). * We both think it only makes sense to merge the infrastructure part into cmake (if it passes review first of course) once we have some functionality that is genuinely useful. So we want to aim at having the infrastructure and the codemodel merged in one go. 1) Infrastructure: 1.1 Communication: * Clients should talk to daemon mode via a socket (libuv supports that), but we also want to support stdin/stdout at least for a "debug mode" * There should be a separate command line switch to start stdin/out mode and for socket mode * This is needed before it makes sense to merge the patch set. 1.2 Protocol versions * We need the daemon-mode to support different protocol versions. These need to be versioned independently of the cmake binary itself and we will try to keep the protocol versions working as long as that is reasonable, but would try to support them for at least a year or two (if there are no overriding concerns). * We want to have the option to mark protocol versions as experimental. Experimental protocol versions come with *NO* guarantees and can change *AT ANY TIME*. If a experimental protocol ends up in a cmake release there still are no guarantees. I would like to see experimental protocol versions in cmake releases, since that makes it really easy for other parties to evaluate changes. In my experience hardly anybody builds custom branches:-/ All this would need to be communicated by cmake e.g. in the release notes. 1.3 Basic Protocol * Client/daemon talk via JSON messages. * All messages have a "type" with a string specifying the type of message. * We (mostly) have a request/reply model. The client sends a request message and will receive a reply or an error. * Requests contain a type, and an optional cookie (which will be returned together with any message sent by the daemon in response to the request). A cookie can be any JSON object. * A reply is a JSON message of type "reply". It contains the cookie of its request and any data that the daemon wants to send its client. * An error is a JSON message of type "error". It contains the cookie of its request and an "errorMessage". * There are more JSON messages for progress information and messages, etc. and we can add more as needed. TO DECIDE: * 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. I like having this as it makes it helps to identify what a reply/error is related to. I often paste a whole string of requests into the daemon and if there is an error it is really easy to see how for things got. * Should we have a split between header (cookie/type/inReplyTo) and data? Stephen suggested passing all data that is from/for the client in a "body" attribute to make messages more uniform. I think that is just adding one more level into the JSON file for no real benefit. 2) Basic Command Set 2.1) Reset (Reset to a state right after daemon start) * Remove this. This is error prone as data structures may not be cleaned out properly. 2.2) globalSettings (Query generators, debug flags, etc.) * Move generators and other static information into a separate cmake commandline invocation (http://public.kitware.com/Bug/view.php?id=15462): * Generators with information on them * CMake version information * Module path * Daemon mode support all should be available in a machine readable way from that command. TODO: Figure out how to get all the generator information, e.g. which values the flags some generator taken can have (architecture, etc.). Stephen volunteered to check into this. * We can report the selected generator/extragenerator here. * Undecided about whether it makes sense to report source/builddirectory here 2.3) setGlobalSettings (set the information from globalSettings) * This is currently used to set sourcedirectory, builddirectory and
