CMake Debugger does not display properties

[Neumann-A]

Brief Issue Summary

Currently the CMake Debugger only seems to show variables and not properties associated with the current directory or global scope:

Note: using cmake-tools build from #3277 to attach to an external cmake debugging session.

(Could also be a CMake issue not passing the required info via DAP? But the CMake issues about the debugger seems to indicate that this is implemented?)

CMake Tools Diagnostics

No response

Debug Log

No response

Additional Information

No response

[gcampbell-msft]

@Neumann-A What type of values are you expecting? I see the "Directories" dropdown in the screenshot. Is that not what you're looking for?

Also, to ensure that this is tracked in the CMake debugger itself, can you post an issue here: https://gitlab.kitware.com/cmake/cmake?

Thanks!

[Neumann-A]

What type of values are you expecting?

I want to see the values of properties vcpkg_global_prop_test and vcpkg_dir_prop_test and all other properties cmake normally has in the scope. So ideally there would be a Properties drop down with entries like global|directory|target|.... which then lists the properties accordingly.

I see the "Directories" dropdown in the screenshot. Is that not what you're looking for?

No. I don't remember exactly what those showed but it was also just some normal variable names.

I don't know what CMake does here but those are just normal local variables where CMakes somehow knows they are directories? (Probably due to file(MAKE_DIRECTORY "${CURRENT_BUILDTREES_DIR}" "${CURRENT_PACKAGES_DIR}"))

Also, to ensure that this is tracked in the CMake debugger itself, can you post an issue here:

The question is if it is already implemented and just missing a request for it here. I read https://gitlab.kitware.com/cmake/cmake/-/issues/21510, https://gitlab.kitware.com/cmake/cmake/-/issues/21510#note_867714 and https://gitlab.kitware.com/cmake/cmake/-/issues/21510#note_1371272 and for me it seemed like that?

See:
One downside to using DAP is that the protocol as specified may not have first-class support for features unique to certain debuggers. For example DAP has no notion of a CMake target or target properties. This proposal solves these issues by leveraging how DAP clients ignore unknown fields to allow vendors to declare their support for extensions during protocol initialization and falling back to represent CMake-specific concepts using more general DAP messages if extension support is not declared.
https://gitlab.kitware.com/cmake/cmake/-/issues/21510#scopes-request

I mean I could also be wrong with that and the support from the cmake side is missing.

[gcampbell-msft]

From the reading you linked to, I think you may be right. I'll confer with the team and assess whether any code fixes need to go into upstream or if it's simply modifications with the VS Code integration.

Thanks for calling this out!