[cmake-developers] CMake Daemon
Tobias Hunger
tobias.hunger at gmail.com
Wed Feb 10 05:37:16 EST 2016
Hi Stephen,
I will then continue down that road.
Next steps are a way to consistently report progress as well as being
able to have several protocol versions at the same time and have a
client pick one.
I will just put them atop my current branch, as that is going to need
basically the same amount of retro-active integration into similar
places as the current changes.
I am not keen on doing that twice:-)
Best Regards,
Tobias
On Wed, Feb 10, 2016 at 12:44 AM, Stephen Kelly <steveire at gmail.com> wrote:
> Stephen Kelly wrote:
>
>> Tamás Kenéz wrote:
>>
>>> That's great and really does open a new world for IDEs!
>>
>> Thanks! Let's see if the interest grows.
>>
>> I've just pushed the daemon code here:
>>
>> https://github.com/steveire/cmake/tree/cmake-daemon
>
> Tobias made a pull request there. Rather than review it there, I will review
> it here for visibility.
>
> https://github.com/steveire/CMake/pull/2
>
> The branch is quite it hard to review, or even to see the particular
> changes, due to large commits and diff noise. If the Daemon reaches a level
> of completeness that it could be upstreamed (See
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15740
>
> ) then these commits (including all of my commits on the branch) would have
> to be rewritten, split, made reviewable etc making heavy use of `rebase -i`.
>
> In a way, we don't have to do that now, but I'm also not very enthusiastic
> about making the `cmake-daemon` branch commits unreadable. I would add your
> commits to the branch if they we split and in the appropriate place (eg,
> with the cmServerProtocol0_1 change early in the cmake-daemon branch).
>
> The changes in your branch are good and useful to more than just QtCreator.
>
> Things that I like in your branch:
>
> * Explicit cmServerRequest and cmServerResponse APIs, which enforce the type
> and cookie consistency.
> * Returning cmServerResponse objects from the cmServerProtocol instead of
> invoking the server from the cmServerProtocol.
> * A way to version the protocol in a future-proof way with C++ classes.
> * Implementation of daemon and protocol error messaging infrastructure.
> (Reporting errors from cmake code requires other refactoring:
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=15636)
>
> So I think that is progress!
>
> Thanks,
>
> Steve.
>
>
>
> --
>
> 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
More information about the cmake-developers
mailing list