Distribute binary artifacts outside vscode extension store

[petr-tik]

Thanks again for all your work on this extension. I am using this to debug rust programs and it's proving very sturdy and user-friendly.

Since you implemented the full DAP server, it would be great to enable users of other editors to use it too.

I am pretty invested in emacs and would like to use vscode-lldb as the backend to my emacs-driven debugging. The dap-mode is working to bring the joys of DAP debugging to emacs users. VS Code offers a very easy install process that I would like to replicate.

I was wondering, if you would be open to packaging up and releasing binary artifacts that can be downloaded from releases for people to use your DAP adapter with other editors.

I have more experience with cargo than I do with CMake and I am happy to dig further, if you would review such PRs.

Running to find all python and executable files in the extension directory after the vscode install shows that most files are python scripts, accompanied by own builds of lldb and some shared libraries. If I understand the CMakeLists.txt correctly, you build them before packaging the .vsix file up, so it should be possible to prepare and push a .zip archive with necessary files

$ find . -type f -name *.py -o -type f -executable | sort -t'.' -k3
./adapter2/codelldb.dll
./lldb/bin/liblldb.dll
./lldb/bin/msdia140.dll
./adapter2/codelldb.exe
./lldb/bin/lldb.exe
./lldb/bin/lldb-argdumper.exe
./lldb/lib/site-packages/lldb/lldb-argdumper.exe
./adapter2/codelldb.py
./adapter2/debugger.py
./adapter2/rust.py
./adapter2/value.py
./lldb/lib/site-packages/lldb/__init__.py
./lldb/lib/site-packages/lldb/embedded_interpreter.py
./lldb/lib/site-packages/lldb/formatters/__init__.py
./lldb/lib/site-packages/lldb/formatters/attrib_fromdict.py
./lldb/lib/site-packages/lldb/formatters/cache.py
./lldb/lib/site-packages/lldb/formatters/cpp/__init__.py
./lldb/lib/site-packages/lldb/formatters/cpp/gnu_libstdcpp.py
./lldb/lib/site-packages/lldb/formatters/cpp/libcxx.py
./lldb/lib/site-packages/lldb/formatters/Logger.py
./lldb/lib/site-packages/lldb/formatters/metrics.py
./lldb/lib/site-packages/lldb/formatters/synth.py
./lldb/lib/site-packages/lldb/utils/__init__.py
./lldb/lib/site-packages/lldb/utils/in_call_stack.py
./lldb/lib/site-packages/lldb/utils/symbolication.py
./lldb/lib/site-packages/six.py

Thoughts?

Side question

Noticed that lldb-argdumper.exe in different directories are the same files

$ diff -s lldb/bin/lldb-argdumper.exe lldb/lib/site-packages/lldb/lldb-argdumper.exe
Files lldb/bin/lldb-argdumper.exe and lldb/lib/site-packages/lldb/lldb-argdumper.exe are identical

Is there a reason they are duplicated or is it something that you can cut down on?

[vadimcn]

Hi,

I was wondering, if you would be open to packaging up and releasing binary artifacts that can be downloaded from releases for people to use your DAP adapter with other editors.

I am not intrinsically opposed to it, however I am not exactly seeking for extra work to take upon :) Could you just extract the files from .vsix packages or even just use them directly? They do contain some files that would be irrelevant for emacs (such as the VSCode extension itself), however these are minuscule compared to lldb shared library, so I would just leave them there.

Speaking of VSCode extension: some features, such as config variable expansion or querying for cargo output artifacts are implemented on the extension side, so you'll need to re-implement at least some of that.

Also, in my experience, things not explicitly tested tend to break, even though "nothing should have changed since the last release"...

So how about this model: whenever there's a new release, you grab .vsix packages, test with your emacs plugin, then host for emacs users to download?

Noticed that lldb-argdumper.exe in different directories are the same files

It's actually a symlink in lldb distribution, however vsce does not preserve symlinks when creating .vsix packages, so it ends up duplicated. I am not 100% sure why Python extension needs this file, but it's so small compared to everything else, I couldn't be bothered to investigate whether I can get rid of it.

[poscat0x04]

Separating the binary from the extension would also benefit NixOS since ld-linux-x86-64.so.2 and liblldb.so are at non-standard locations.