Modularize STM32CubeIDE for VSCode: Split debugging support VSCode extensions from Core + Build

[elbe_25]

For users having / wanting / needing their own VSCode C++ setup it would be very beneficial to have the STM32 debugging VSCode extensions not rely on the rest of the STM32 Cube extensions.

Neither do I want nor do I need all of the bundle management, CMake replacement, code analysis and what not stuff the VSCode extensions are doing.

Currently, st-cube-ide-stlink-gdbserver, st-cube-ide-debug-generic-gdbserver, st-cube-ide-debug-core (whatever I would really need) pull in the Core and, especially annoying and not really understandable for me, the CMake Support extension.

I'd appreciate to have a debugging support extension that works well with any build + edit setup, just like cortex-debug.

[elbe_25]

BTW: This topic is intended to summarize parts of this post:

Disable Intellisense: You have both the Microsoft C++ ... 

[vincent_grenet]

@elbe_25 

Thank you for reporting your need.

We already have this option as part of our plan.

Note: You cannot avoid the STM32Cube bundle dependency. This is how we provide utilities such as GDB servers, which cortex-debug does not promote. Our goal is to enable support for any build system based on the end user's choice, supporting a debug experience starting from an .elf file. We aim to promote a debug-only STM32CubeIDE Visual Studio Code extension extra pack. Would this be helpful or valuable to you?

Unfortunately, I cannot provide a delivery date at this time.

[elbe_25]

@vincent_grenet 

Thank you for your reply.

Your goal you stated above sounds good to me.

For the setup/edit/build cycle the bundle management probably is a good idea for users who want or need a short time to get up and running.

For the debug extensions, I don't see the necessity to keep it integrated into your bundle management.

Compared to setup/build you need only relatively few extra files (gdbserver, svd files and the like) for which the usual VSCode extension update mechanism should be well suited.

Until the shiny goal of a more or less standalone debug extension is reached:

In the mean time it would really help if you remove the dependency from the debug to the STM32Cube CMake extensions. I don't understand why it's there in the first place.

I already can use your debug extension with my own C++ build setup.

The main problem is that the STM32Cube extensions (I assume the CMake one) keep destroying the .settings by reinserting cube-cmake again and again.

Best regards,

Titus

[vincent_grenet]

@elbe_25 

The STM32Cube CMake extension is currently required to obtain the active project. This extension is useful when the workspace contains multiple projects, as it enables identification of the target device and binary file needed to initiate a debug session.

The primary purpose of the bundle is to provide a GDB server. However, it includes additional components. The bundles also support a programmer, an RTOS proxy, and various GDB servers. Integrating all these components into a single package is more complex than it initially appears. All these components have to be delivered to local host. VS Code extensions are not aimed to. Let's consider VS Code extension like GUI contribution only.

[elbe_25]

Hello Vincent,

I understand, that's what I expected.

Again: I do not want to convince you to drop the current design of your own bundle management and stuff. I'm sure this will be a great solution for novice users, or to reduce the development environment setup time in general.

All I'm saying is that folks who want or need to take care of their complete C++ ecosystem should not be forced to install quite intrusive stuff (as your CMake extension appears to be) just to get going with debugging.

For the concrete problem regarding the depedeny on the CMake extension: Just make it optional.

If installed, automatic configuration of the debug target works, if not installed, the user is expected to know where his ELF output file is and what controller is the target machine.

Or, put in your words, make optional the non-GUI contributions of your extensions.

[vincent_grenet]

@elbe_25 
Yes, I confirm that our goal would to make it optional.