Status of CMake debugger

I see that a 2 year old closed MR attempted to add a debugger mode to CMake but was never merged. Have there been any activity to add a debugger to CMake since then (~2 years ago)? If the approach in the closed MR still looks reasonable, I’d be interested in doing the work necessary to get this functionality.

Alternatively, the Debug Adapter Protocol has gained some traction since 2017 with several tools supporting it like Visual Studio, Visual Studio Code, Vim, and Emacs. I could rework the existing debugger to support this protocol instead, which could make it easier for additional tools to add debugging support in the future.

AFAIK there has been no further progress. Furthermore, IIRC that MR was based on the server-mode protocol infrastructure. The server mode has been deprecated in favor of file-api and most of its infrastructure will be removed along with the server mode. Therefore the design space remains wide open.

Honest question (and let me disclaim, up front, that I haven’t seen the “discussion in the developer mailing list”) : What is the envisioned utility of such a debugger? What functionality is expected/proposed?

In fact, more generally: What, precisely, would be debugged with such a debugger?

  • Obviously not CMake’s output, since that’s just build files.

  • Perhaps the parsing of the CMakeLists.txt files could be debugged. --trace and --trace-expand already provide pretty good visibility into the line-by-line processing of CMake statements.

(However, a parser debugger would be useful for wiring up live syntax checking of CMakeLists.txt files in a code editor.)

  • Maybe the variable assignment and expansion that goes on during processing, but again --trace-expand covers that somewhat, plus there’s the contents of the CMakeCache.txt file. During execution, it’s possible to use CMakePrintHelpers to perform some rudimentary debug-printing of variable or property values, though it’s admittedly lacking as a debugging tool.

(Still, here again code editors can provide hinting and lookup functionality if they’re being fed parser data for the currently-open file.)

  • And then we come to the elephant(s) in the room, the major aspects of CMake’s functionality that currently don’t ever get stored on disk for convenient examination, nor are they able to be displayed with any of the current tools:
    • The definition and interpretation of targets
    • Processing/expansion of generator expressions

So, is that the goal here, to reveal more of those (currently-mysterious) aspects of CMake’s processing of the build system configuration to users/developers? Or is it more about wiring CMake into code editors so they can offer enhanced coding features?

Just trying to calibrate my anticipation and enthusiasm accordingly. :wink:

You can find an early work of what I believe is the original attempt in this video from FOSDEM 2018: https://ftp.belnet.be/mirror/FOSDEM/2016/k4401/enabling-gui-tools-for-cmake-code.mp4

This ultimately lead to the now deprecated cmake-server mode for completion and code model (target list,…) but also had a debug mode for:

  • reading variable values
  • tracing their modifications
  • exploring where these are modified,…

Thanks for that perspective @ferdnyc! I work on C++ tooling professionally and was originally envisioning this as a way to use existing IDE debugging interfaces that are familiar to developers to debug the execution of CMake scripts. --trace and --trace-expand certainly already provide large pieces of this functionality, but I think there’s still benefit from interactive debug sessions because they can provide functionality like seeing all variables values in scope, modifying variable values during execution, or even changing the “instruction pointer” as the script executes by skipping certain commands or rerunning others.

Admittedly, I spend more time writing tooling for C++ and CMake than I spend actually writing CMake scripts, so if more experienced users think this kind of debugger tooling wouldn’t actually be very useful in practice, I’m 100% open to reconsidering the approach here. Please chime in if you have opinions or examples of bugs that were difficult to diagnose with existing tools!

I haven’t given a lot of thought to debugging generator expressions or targets, but that sounds like a great direction to investigate further. Given how open this design space currently is, I’ll spend some time putting together a more complete proposal that makes the expected utility and functionality of a debugger clear, then loop back to this thread.