> > 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.k...@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 >
-- 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