[Discussion] DAP support

[N-R-K]

cmake has debugging support via --debugger which uses the Debug Adapter Protocol.

I see muon has some WIP debug support but I don't see any mention of DAP. Maybe the debugger can also support DAP so that it can work with alternative front end/editor plugins etc.

[annacrombie]

Yes, I want to implement DAP. The main blocker for me is I don't know of a good DAP client I'd want to develop against. I use neovim and haven't really been that impressed with the stuff available yet. Part of it is that I just prefer standalone debuggers, and kind of dislike it when my editor gets cluttered up with breakpoints and output windows. I might see if I can get dcmake pointed at muon though, not sure how cmake specific it is?

[annacrombie]

Okay, dcmake is nice and small and it looks easy enough to hack muon in. I'm going to start on this and see what I come up with.

[skeeto]

A little tip for dcmake: View -> DAP Log. It's not shown by default because it's mainly for debugging the interop, but that's your case and might help you. If there's a way this could work better for you let me know.

[annacrombie]

Update: it is going pretty well, the trickiest part is getting stepping right but it is passable for now. I just implemented children for the variables command and it is pretty neat to see the compiler object live in the debugger, with all of its handlers. And it is reusing the reflection api that the serialization system uses!

[skeeto]

Wow, I tried it out myself and that's neat to see in action! I'll need to consider what it means for dcmake to support muon, perhaps in some kind of muon mode. Things that come to mind:

• It's hardcoded for cmake --debugger and so you had to modify dcmake to rig it up to muon. It will require some UI to switch to muon (invoking it as dmuon?).
• Cache Variables probably don't have an analogue. Maybe the same for Tests. (I need to learn more about Meson.)
• It assumes ; in values are list delimiters, which is how CMake expresses lists even though the interop.
  • The unfolding of cc in the screenshot suggests more muon-specific dcmake changes?
• It relies on a hack in the CMake interop so that starting the debuggee with F10 stops on the first line (a la Visual Studio and similar), which doesn't currently work in in the muon interop.
• Hardcodes some CMake debugger output so it doesn't show in the Output window. My intention is for that part to be invisible.

(Edit: Oh, doh, I see the issue open now!)

[eli-schwartz]

• Cache Variables probably don't have an analogue. Maybe the same for Tests. (I need to learn more about Meson.)

Not familiar with cmake --debugger, but the Meson grammar doesn't allow for "cache variables".

CMake cache variables blur erase the line between set() (CMake's equivalent of equals-assignment) and -D (cli interface to configure options). In CMake, anything is a variable, but the number of variables that have blank values approaches infinity. The number of meaningful variables is generally, though not always, documented in a wiki or readme file. The CMake cache allows you to poke at the internal values of things (any DSL level variable) that aren't necessarily settable (either because they are always recalculated by CMakeLists.txt or because they are undocumented and unsafe to set, and attempting to modify the values is undefined behavior).

Meson only supports cli interaction via an options protocol, with lookup via foo = get_option('foo') corresponding to the CLI argument -Dfoo=value. There is naturally going to be some in-memory structure representing the values of DSL variables, but it's going to be some internal detail of the implementation (whether that be meson.py, or muon) and probably need special exposure to the debugger. There should be no particular assumption that things like the details of the selected compiler are accessible in the same way -- compiler detection is opaque and details about it are expected to be fetched by DSL methods that return a value to the build script, so the compiler internals will likely be stored by an entirely different in-memory structure.

Meson does support test() registration to a unittest framework (muon test -l, meson test --list)

• It assumes ; in values are list delimiters, which is how CMake expresses lists even though the interop.

  • The unfolding of cc in the screenshot suggests more muon-specific dcmake changes?

cc is an assigned variable that contains an object with custom DSL methods, it isn't either a string or a list. The unfolded properties in the screenshot appear to be a debugging view of all the information that is hidden away inside the opaque interface (and often also available as a DSL method, e.g. version = cc.version() will retrieve the ver[toolchain_component_co probably mpiler] as a string, and cmd_array = cc.cmd_array() will retrieve the cmd_arr[toolchain_component something as an array of strings).

In CMake it would probably be a cache variable again, prefixed as e.g. CMAKE_C_COMPILER_* (e.g. CMAKE_C_COMPILER_VERSION), because CMake does not have objects.

[annacrombie]

The unfolding of cc in the screenshot suggests more muon-specific dcmake changes?

No, that didn't require any actually. It works presumably the same way cmake does by adding a variablesReference to the response to the variables command when that object has children. It was using some local changes that I only pushed up this morning.

The unfolded properties in the screenshot appear to be a debugging view of all the information that is hidden away inside the opaque interface

Correct, the c struct is this:

struct obj_compiler {
	obj cmd_arr[toolchain_component_count];
	obj overrides[toolchain_component_count];
	uint32_t type[toolchain_component_count];
	obj ver[toolchain_component_count];
	obj ver_raw;
	struct target_triple triple;
	obj libdirs;
	obj fwdirs;
	enum compiler_language lang;
	enum machine_kind machine;
};

And it is reflected when the vm starts up like this:

	vm_reflect_obj_field_for_each_toolchain_component(obj_compiler, obj, cmd_arr);
	vm_reflect_obj_field_for_each_toolchain_component(obj_compiler, obj, overrides);
	vm_reflect_obj_field_for_each_toolchain_component(obj_compiler, uint32_t, type);
	vm_reflect_obj_field_for_each_toolchain_component(obj_compiler, obj, ver);
	vm_reflect_obj_field(obj_compiler, obj, libdirs);
	vm_reflect_obj_field(obj_compiler, obj, fwdirs);
	vm_reflect_obj_field(obj_compiler, enum compiler_language, lang);
	vm_reflect_obj_field(obj_compiler, enum machine_kind, machine);

[skeeto]

It was using some local changes that I only pushed up this morning.

Ah, that's what I was missing. Your branch at the time only returned "<obj compiler>" for the value, and I was wondering how that unfolded. How I see the unfolding with your latest changes.