[cmake-developers] Debugger for CMake

[Justin Berger]

>
> I'd like to see if we can make the debug server part of the existing server
> mode rather than adding another mode as the original MR does.  The current
> server mode already has infrastructure for protocol version negotiation,
> capability listing, etc.  We should be able to use/re-use that as
> appropriate.
>

I agree on the maximizing code reuse, but that doesn't require them to use
the same operational mode -- the two modes do fundamentally different
things; even while sharing most internal components. Is the idea that you
could only start a debug session if you have cmake-server running, and then
you instruct it to configure?


> As for the server blocking on the configure call, that is in response to
> the
> client's request for configuration of the build tree.  With the currently
> available protocol blocking is okay.  If additional internal granularity of
> responsibility is needed for a debug server then such refactoring would be
> appropriate.  As long as the current protocol remains unchanged from the
> perspective of the client then the debug server can choose to offer a
> different protocol on top of a common internal implementation.


This goes towards the point of having them on different sockets / pipes.
None of the commands cmake-server handles make sense when running -- so
much so, that it can just block requests while running. And none of the
commands you'd send the debugger would make sense when you aren't running
configure. If the existing connection was used for both purposes, it seems
like it would necessarily end up making client and servers code paths
diverge as soon as a message was received based on which state you were in.
If you just use a different socket (or whichever transport method) it
seemed like you could keep those logic concerns cleanly separated -- even
while reusing, on both ends, all code right up to the point of digesting
received messages.

Admittedly the current branch does use straight JSON by default instead of
the '[== "CMake Server" ==[' buffering strategy to delimit json messages
off the wire, but I wasn't entirely sure the reasoning behind those
delimiters since you know when a message ends just based on the root JSON
object closing. That can be swapped easily, or configured; but it'd be nice
to have it as an option on both server and the debugger since API consumers
might find it not ideal to write and work with the custom tags.

I've updated the branch on gitlab with a lot more stuff; namely a minimal
json server which works with an Intellij plugin and thread safety
measures.Should I resumbit the MR to continue the discussion there?

On Mon, Feb 13, 2017 at 12:59 PM, Brad King <brad.king at kitware.com> wrote:

> On 02/02/2017 01:15 PM, Justin Berger wrote:
> > I haven't seen the proposals on how to implement alternative language
> > front ends from the technical side; but the debugger shouldn't have any
> > explicit dependence on the front-end language; its called via hooks
> > (right now in cmMakefile) and has some introspection capabilities via
> > that same class.
>
> The cmMakefile class is the core implementation of the current CMake
> language (it's name is historical), so placing the hooks in it would tie
> the debugger to the current language.  I don't think there is anything
> wrong with that because the whole point is to debug code written the
> current language.
>
> -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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170213/2c909a23/attachment.html>