I’d like to propose publishing an official LLDB extension in the Visual Studio Marketplace. We already have two official extension published under the LLVM umbrella. We also have an unofficial version from @lanza though that hasn’t been updated in several years.
Looking at the MLIR extension, it uses Github workflows to automatically pull in changes from the llvm-project repository and to build and publish the extension in the marketplace. I would like to do something similar for our extension as I think that would work for us as well.
The only really tricky part about the extension is the lldb-dap binary. Both the clangd and MLIR extension don’t distribute binaries as part of the extension, and instead let you specify the path to it. I’m proposing we take the same approach.
Please let me know what you think, have concerns and/or if you’re interested in helping out with this effort!
I’ve been thinking the same thing, Jonas. An official lldb-dap extension in the marketplace will solve some issues with my downstream toolsets (Hexagon and RISC-V right now). In fact, when I talked to my boss today I mentioned putting an extension on the marketplace!
I think allowing the user to specify the lldb-dap to use would be ideal. That way I can use the same extension to point to different installations of tools; perhaps even lldb-vscode for 2022 and earlier Hexagon releases.
This is music to my ears.
It turns out that last year I added some logic in lldb-dap to produce a distributable .vsix installation for VSCode. The instructions are in the lldb-dap README. As mentioned in that README, there are two ways to create that vsix file. One contains the debugger (lldb-dap + liblldb) and the other doesn’t contain it, in which case the user has to specify the path manually.
The only really tricky part about the extension is the lldb-dap binary. Both the clangd and MLIR extension don’t distribute binaries as part of the extension, and instead let you specify the path to it. I’m proposing we take the same approach.
I also think we should follow that approach, however it’s unfortunate that you can’t install lldb-dap using system’s package managers like apt or brew. It would be nice to also include lldb-dap in the lldb packages distributed by those package managers.
And yes, I’m very willing to help. Let me know where you want to coordinate the effort.
Including lldb-dap in packages is up to the package maintainers. It’s simple to build, so adding it to an lldb package is trivial.
We’d still want to be able to point to an arbitrary lldb-dap (or lldb-vscode, for older installations) to handle cases where someone wants to use a specific version of lldb, or is using a non-system lldb, like in an embedded toolchain.
We’ve also got a group making a true IDE in vscode for Hexagon, and they want to be able to specify a path to lldb-dap in their IDE prefs, which sounds like a perfect case for your library build.
I think the course of action would be to simply ship official VSCode extension without lldb-dap. Then, the extension can by default use lldb-dap from PATH, if available, or the user can specify it manually via a config.
The existing code in the LLVM repo already has that config available. We’d just need to teach it to use lldb-dap from the PATH.