In continuation from the discussion in the developer mailing list,
We just need a different command-line option for a debug client to start a debug server instead.
Currently the command line looks like this:
cmake --debugger=<connection> <other_options> <source_dir>
cmake --debugger=<connection> -P <script_file>
where connection can be 'stdin' or a port number to talk via a JSON protocol. Let me know what changes I should make to that. I also made it look at the environment variable CMAKE_DEBUGGER for the same connection. The idea here is that this way you can debug cmake instances which were started as external commands from within cmake. The approach needs a little more fleshing out though since this only works if you set the port to '0' so it picks randomly and it currently doesn't have a good way to advertise the debugger is up.
Currently it is built into a library of its own; it might be worth just rolling it straight into cmake server's library and use the same enable flag for it.
The reference json server implementation isn't currently using the cmake-server bracketing. It is currently using YAJL as a streaming parser for just plain JSON(I wrote this before it came up on the dev list). Let me know if I should keep / remove / add an option flag for that behavior.
There was also somewhat serious refactoring into some of the cmake server core so that a lot of the same connection / loop handler logic could be shared. I ran the unit tests for cmake server but am not sure the best way to verify the refactor didn't break anything other than that. This refactor also should allow connections to the cmake server via TCP/IP sockets. It might be worth adding command line flags to use that connection since some languages don't have great support for named pipes and libuv does all the heavy lifting for us.
The other outstanding question is how to integrate this with cmake-server functionally. I left that matter alone for now. The thing that makes sense most to me right now is add a flag to the 'configure' message that sets up the debugger and runs the debugger on the specified port / pipe. Other than that, the option would be to add a flag to enable debug mode, and while the configure is going the debugger protocol is in use until the configuration is complete, which then it swaps back to the other command set. As I said in the thread, I think the second option has some messier implementation details on both sides, but I'm open to either one.