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.txtfiles could be debugged.--traceand--trace-expandalready 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-expandcovers that somewhat, plus there’s the contents of theCMakeCache.txtfile. During execution, it’s possible to useCMakePrintHelpersto 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. 