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.
Greg > On Mar 13, 2019, at 12:50 AM, Pavel Labath via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > On 12/03/2019 20:34, Leonard Mosescu via lldb-dev wrote: >> Greg, what do you think? >> On Tue, Mar 12, 2019 at 11:50 AM Qianli Ma <chienl...@google.com >> <mailto:chienl...@google.com>> wrote: >> Hi lldb community, >> I am currently working on a project related to lldb. I'd like to >> write a DAP RPC server similars to lldb-vscode.cc >> >> <https://github.com/llvm-mirror/lldb/blob/master/tools/lldb-vscode/lldb-vscode.cpp> >> but >> exports I/O to internal RPC clients. Doing so requires me to reuse >> some functions defined in lldb-vscode.cc >> >> <https://github.com/llvm-mirror/lldb/blob/master/tools/lldb-vscode/lldb-vscode.cpp>. >> However as those functions are defined using forward declaration I >> am not able to do that. >> I'd like refactor the code a bit. More specifically, I'd like to >> extract all helper functions in lldb-vscode.cc >> >> <https://github.com/llvm-mirror/lldb/blob/master/tools/lldb-vscode/lldb-vscode.cpp> >> into >> a separate file and create a header for it. BTW, IMO it's good to >> make this lldb-vscode more general so that it can be used by other >> debugger frontends besides vscode. >> Please let me know WDYT and how I can proceed to submit changes for >> review. >> Thanks and Regards >> Qianli > > 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/. > > regards, > pl > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
