Greg, what do you think?
This seems reasonable to me. It’s worth pointing out though that in regards to the last comment “IMO it’s good to make this lldb-vscode more general so that it can be used by other debugger frontends besides vscode”, despite the name lldb-vscode, there is actually nothing here that is specific to VSCode. It reads DAP requests on stdin and responds with DAP responses on stdout. That’s literally it. The only thing vscode specific about it is the names of the source files and some internal classes. I actually wouldn’t be opposed to changing it to lldb-dap
The way I understand this idea, you want to make (parts of) lldb-vscode a library. The way this is usually done in llvm is that you put all of the library stuff in a separate folder, with its own headers, cmake target and everything. Then, you can make lldb-vscode executable (or whatever its called) link against that library. Your downstream tool can do the same.
I think doing that is a good idea. The only part we need to figure out is where to put the new library code. Normally, all our library-ized code lives under source/, but this library would be special in that it sits on top of the SB api rather than beneath it. So, even though it sounds a weird to have a library living under tools/, it might be better to have the new library be there instead of under source/.
Fine to refactor any way that makes it easier for people to re-use or add new VS Code DAP plug-ins! I agree with all comments so far.