# Status of CMake debugger

**URL:** https://discourse.cmake.org/t/status-of-cmake-debugger/567
**Category:** Development
**Created:** [February 4, 2020, 12:56am UTC](https://discourse.cmake.org/t/status-of-cmake-debugger/567 "2020-02-04T00:56:53Z")
**Posts on this page:** 1
**Showing post:** 10

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [November 3, 2020, 9:18pm UTC](https://discourse.cmake.org/t/status-of-cmake-debugger/567/10 "2020-11-03T21:18:39Z")

</div>

> [@ben](#):
>
> - Step into (single step), step over, and stepping out of the currently executing macro or function.

We may need to think a bit about what this means for the various `cmake_language()` subcommands.

Another thing that users may want to have access to is the currently defined export sets. The install components would already be available through the `COMPONENTS` global pseudo-property.

An interesting idea might also be code injection. If we can find a way to easily inject CMake code to be executed upon a breakpoint, that opens up a whole range of flexible debugging capabilities. Maybe we can leverage the `cmake_language()` functionality somehow for this?

I would personally be happy with genex support coming later. The other debugging features seem easier and less invasive and would likely cover many already useful debugging situations. If we manage to provide code injection, that might offer more choices for this as well (but I haven’t thought that through very far).

---

_[View the full topic](https://discourse.cmake.org/t/status-of-cmake-debugger/567)._