STM32CudeIDE extension for Visual Studio Code does not play nicely with CMake extensions

[ADunc.1]

I normally use the CMake Tools extension (by Microsoft) for compiling cmake projects in visual studio code.  After installing the STM32CubeIDE extension, the CMake Tools extension stopped working.  Presumably to do with the stm extension changing to using cube-cmake.  After uninstalling all STM32CubeIDE extensions, reinstalling CMake Tools, restaring VS code, the CMake Tools extension is still still broken.  Trying to configure a project through the IDE gives the following output:

[cmakeExecutable] CMake executable not found in cache. Checking again.

[proc] Executing command: cube-cmake --version

[proc] The command: cube-cmake --version failed with error: Error: spawn cube-cmake ENOENT

[proc] Executing command: cube-cmake -E capabilities

[proc] The command: cube-cmake -E capabilities failed with error: Error: spawn cube-cmake ENOENT

[main] Building folder: core2-firmware

[cmakeExecutable] CMake executable not found in cache. Checking again.

[proc] Executing command: cube-cmake --version

[proc] The command: cube-cmake --version failed with error: Error: spawn cube-cmake ENOENT

[proc] Executing command: cube-cmake -E capabilities

[proc] The command: cube-cmake -E capabilities failed with error: Error: spawn cube-cmake ENOENT

[rollbar] Unhandled exception: Unhandled Promise rejection: build Error: Build failed: Unable to configure the project

It seems the stm extension permanently alters something for the cmake executable used.

It is not great that the stm extension is not fully standalone and isolated like other extensions...   I am also not sure how to fix this now either!

[ADunc.1]

As a follow up,  I noticed the folling are left behind in the settings.json file after an uninstall of all STM32CubeIDE extensions:

    "STM32VSCodeExtension.cubeCLT.path": "c:\\ST\\STM32CubeCLT_1.16.0",

    "cmake.environment": {

        "PATH": "c:/Users/Ashley/.vscode/extensions/stmicroelectronics.stm32cube-ide-build-cmake-1.42.2/resources/cube-cmake/win32;c:\\Users\\Ashley\\.vscode\\extensions\\stmicroelectronics.stm32cube-ide-core-1.0.3\\resources\\binaries\\win32\\x86_64;${env.PATH}"

    },

    "stm32cube-ide-clangd.detectExtensionConflicts": false,

It also leaves this setting behind which seems to be the main culprit.  Needs to be changed to "cmake"

Perhaps the STM3CubeIDE extension should set this on a per project basis or something, so it doesn't mess up the CMake Tools extension.

But, this still does not resolve the problem.  cmake is still called on the command line with -DCMKE_COMMAND=cube-cmake.  It turns out that the stm extension also sneakily modifies the hidden settings.json file in your projects .vscode folder by adding:

    "cmake.configureArgs": [

        "-DCMAKE_COMMAND=cube-cmake"

    ],

    "stm32cube-ide-clangd.path": "cube",

I am not aware of ever telling the stm extension that my project should use stm tools!

[Julien D]

Hi @ADunc.1,

What you describe is entirely valid:

1. Once a project is set up to work with STM32Cube extensions, manual changes to its .vscode/settings.json are needed if our extensions become uninstalled. Mainly, to clean up our integration with CMake Tools: the cmake.cmakePath and cmake.configureArgs settings should be removed, and optionally stm32cube-ide-clangd.path and stm32cube-ide-clangd.arguments too.
2. The global setting cmake.environment may still contain unreachable or old paths after STM32Cube extensions are uninstalled. This should not cause any issues, but please explain your broken use case if it does.

The fact is that VSCode does not offer a rich API to allow extensions to perform a full cleanup once they are uninstalled. Here is the developer documentation: https://code.visualstudio.com/updates/v1_21#_extension-uninstall-hook. Running an external Node process breaks the link to your currently running VSCode instance, including its settings, opened folders, and so on.

The same applies to CMake Tools integration; the Microsoft extension does not offer any public API that allows smoother integration. That’s why we chose to insert our integration directly into the project's .vscode/settings.json to avoid breaking other running projects that are not necessarily STM32 projects.

[ADunc.1]

@Julien D Thankyou for the detailed reply.

The project in question here was not a STM32CudeIDE project.  It is a standalone project.  I dont know how it got associated as a STM32CubeIDE project.

I am still not clear if it is possible to have the STM32CubeIDE extension installed, and CMake Tools, in a way that allows building both standalone cmake and STM32CubeIDE projects using the correct cmake path (when clicking the build button on Visual Studio Codes bottom bar).

[Julien D]

By standalone project I assume it is a cmake project.

Then, normally, if it has been associated it is because you choose 'yes' at some point when this notification popup:

Or you might have clicked on the Setup STM32Cube project(s) action:

Otherwise, we clearly have troubles here, and I would be pleased to receive your scenario that leads to this issue.

To address your last point, the promise is that you can fully develop two projects simultaneously: one being an STM32CubeIDE project (with our settings in .vscode/settings.json), and the other a generic CMake project. Both are handled by CMake Tools and can be built via the bottom bar action. Feel free to reach out if something does not work as you expect.

[ADunc.1]

OK, thanks for your help.  I don't remember clicking on those popups, but maybe I did...

My scenario is that I have a completely standalone cmake project (it just so happens to be for an STM32, but has its own cmake build system).  When I am working on that project I want it to just build like it always has with CMake Tools only.

I added the STM32CubeIDE extension as I wanted to test debugging this project on real hardware in VS Code.  I normally use the STM eclipse based IDE for this project, with a custom launch configuration.  I build it outside the IDE first, usually in VSCode.  

I also have other projects, like STM32CubeMX generated ones that are edited and launched through the eclipse IDE.  I thought maybe I could combine all my editing and debugging into VSCode.

[Julien D]

I confirm that what you described should be possible.

Even if you want to debug only your STM32Cube project with VSCode and build it using another method, in that case you need to manually configure your launch.json for debugging with the appropriate attributes.

[ankes]

Hi @ADunc.1,

I can confirm that the STM32CubeIDE extensions do work properly with both projects that embrace the STM's extensions, and projects which do not, and at the same time, too.

You can find a practical example from a code repository I am currently developing: https://github.com/anttikes/usb-fm-radio.

Key points:

• Firmware is built using STM-provided tools (via the bundles system) and extensions; it uses CMake Presets
• GUI is built using a system-wide CMake & Ninja from Qt's own installer; it uses the CMake Kits that are automatically detected and maintained by Qt's extensions
• Choosing between the two occurs automatically with the help of CMake Tools' "auto-select folder" feature; when you open a file in Firmware, the preset side is active. When a file from GUI, the kit system.
• The "auto-select folder" feature requires using VSCode's multi-root workspaces; the workspace file is at the root of the repository.
• In addition to the project-specific settings and workspace settings files, some settings are also maintained in "Preferences: Open User settings (JSON)" by the STM's extensions, most notably "cmake.environment" which is crucial for the "cube-cmake" to work.

Feel free to take inspiration from the way I have set things up, if that's of any help.

[ADunc.1]

@ankes Thanks for taking the time to explain your configuration.   Maybe I will brave up and re-install the stm32cubeIDE extension and have another go with my projects.