[RFC] Automatically download lldb-dap

Subprojects LLDB
1

TLDR: Extend the lldb-dap extension to automatically download lldb-dap?

Problem description

With the lldb-dap VS-Code extension published to the Marketplace (see previous discussion in [RFC] Publishing an official LLDB extension in the Visual Studio Marketplaces), using lldb-dap already got much, much simpler.

However, users still need to procure the lldb-dap binary from somewhere before they can use the VS-Code extension. It would be great if we could provide a better out-of-the-box experience for users.

Prior art: clangd

The clangd extension was facing a similar issue: It needs the clangd binary to properly function.

The problem was solved by:

Proposal

I think we should provide the same user experience as clangd does: If the lldb-dap binary was not found, we should prompt the user if he would like us to download the lldb-dap binary. Maybe we could even reuse (parts of) clangd’s download management code for this.

For hosting the pre-built binaries, I would consider to simply use the binaries from LLVM’s Github Release page. Those packages do already contain the lldb-dap binary today. They might be a bit large, as they contain all of LLVM, clang, clangd, clang-tidy and many more binaries we wouldn’t need. But despite the large download, the end-to-end user experience would already be significantly improved. And maybe there is a chance to also publish more fine-grained packages in the future.

CC @wallace @JDevlieghere @clayborg re lldb-dap
CC @sam-mccall @hokein re their experiences with a similar mechanism for clangd and re code-reuse for download manager
CC @tstellar @tobiashieta re more fine-grained release packages

1 Like
2

Which OS/Arch combos would we need a lldb-dap build for?

3

lldb-dap, by itself, is incomplete. The user would also need to download the lldb shared library (liblldb.so/liblldb.dll/lldb framework) and the lldb Python module (or LUA equivalent, for LUA).

Downloading just lldb-dap would be good to add it to a distribution that didn’t include it already, but do any vendors do that?

BTW - the new extension works with lldb-vscode from older releases as well as lldb-dap.

4

Which OS/Arch combos would we need a lldb-dap build for?

I guess the existing OS/Arch combos (Linux, macOS, Windows) are a very good start. Those are also the OS/Arch combos provided by clangd. And if it works for clangd (which has a much larger user base than lldb-dap), we should be fine.

Maybe, for macOS a fat-binary would still be useful, but not sure about that, yet. Let’s first see if it’s possible to determine the processor architecture reliably from JavaScript and then pick the correct binary.

So the ask here would essentially be:
Keep the build as is, but upload additional .tar.xz files containing subsets of the files which are already produced in the Github runners

I hope that the LLVM_DISTRIBUTION_COMPONENTS CMake setting can be used in order to package just the components required by lldb-dap. (But I didn’t check this, yet.) Also, I don’t know how it would be possible to build multiple packages from the same CMake directory (1: the overall LLVM distribution package as exists today; 2: the lldb-dap distribution). If we manage to reuse the same CMake directory, I we only need to build LLVM once, and would incur minimal additional build costs.

lldb-dap, by itself, is incomplete. The user would also need to download the lldb shared library (liblldb.so/liblldb.dll/lldb framework) and the lldb Python module (or LUA equivalent, for LUA).

Right, I was a bit imprecise in my original message. I would propose to package every thing necessary for lldb-dap into an archive. Similar to how the clangd archives also contain some headers and not only the binary itself.

I hope that the LLVM_DISTRIBUTION_COMPONENTS CMake setting can be used in order to package just the components required by lldb-dap.

BTW - the new extension works with lldb-vscode from older releases as well as lldb-dap.

This would still be the case. If you download lldb-vscode manually, you can still point the VSCode extension to it

5

re their experiences with a similar mechanism for clangd and re code-reuse for download manager

From our experience, the downloader has worked well for us. It’s currently used in both the vscode and coc extensions for clangd.

If you plan to adopt a similar download approach for lldb-dap, I think much of the clangd downloader code (from node-clangd) can be reused. However, this would require some refactoring as there are some clangd-specific bits there. We could abstract a more general downloader module, making it reusable for both node-clangd and your extension.

6

I think this is a fantastic idea. Unlike most extensions, the lldb-dap extension doesn’t just work, and this initial set up can be error prone and lead to some people not using LLDB at all, even when it’s much better than other similar debuggers like gdb.
Yeah, as part of making LLDB better, working on this downloader would be great for user adoption.