"CMake build" extension fails when files are in a sub-folder

[ankes]

Hi,

The new STM32Cube for Visual Studio Code looks really nice but it suffers from (at least one) serious flaw: it does not work correctly when the target project is in a sub-folder.

This means every "multi-project repository" in the world just flat out doesn't work. Especially mine, where the repository contains not only the schematic but also the firmware and a GUI application.

I have attached a sample ZIP to this post which exhibits the issue. Extract both subfolders to a blank directory

• If you open "advanced-sample-cmake" from the root, everything works
• If you open "Subfolder" from the root then everything falls apart

Irony is that "Subfolder" contains the exactly same files than the other. The "STM32Cube CMake build" extension says "Could not configure code indexing until an active project is set" and stops right there.

Note that I can (somewhat) work around this issue by cloning my repository and then opening the subfolder in VS Code:

• The "git" extension really does not like this, and suggests opening the parent directory instead
• Git submodules do not work when I do this
• Git change history does not work either

[Pavel A.]

What is surprising here? Git does not support files outside of the repository subtree. On the other hand Cmake supports subdirectories (CMakeLists.txt with add_subdirectory statements) 

[ankes]

This post is about the "STMCube CMake Support" extension. Not git or CMake. Sorry for being unclear.

If I open the "advanced-sample-cmake" folder from the zip, I see this in the extension's debug output:

2025-11-06 22:42:31.773 [Info]  Adding cube-cmake path to environment: c:/Users/antti/.vscode/extensions/stmicroelectronics.stm32cube-ide-build-cmake-1.42.2/resources/cube-cmake/win32
2025-11-06 22:42:34.279 [Info]  Activating STM32Cube configurations for the code indexing feature...
2025-11-06 22:42:34.290 [Info]  Configuring code indexing for 'e:/advanced-sample-cmake'
2025-11-06 22:42:34.341 [Info]  Build folder is E:/advanced-sample-cmake/build/Debug
2025-11-06 22:42:34.345 [Info]  Updating .clangd configuration file (e:/advanced-sample-cmake/.clangd)
2025-11-06 22:42:34.355 [Info]  Updating c/cpp configuration file (e:/advanced-sample-cmake/.vscode/c_cpp_properties.json)
2025-11-06 22:42:34.359 [Info]  Watching for E:/advanced-sample-cmake/build/Debug/compile_commands.json changes...

And if I open "Subfolder", this is what I get instead:

2025-11-06 22:38:57.036 [Info]  Adding cube-cmake path to environment: c:/Users/antti/.vscode/extensions/stmicroelectronics.stm32cube-ide-build-cmake-1.42.2/resources/cube-cmake/win32
2025-11-06 22:38:58.111 [Info]  Activating STM32Cube configurations for the code indexing feature...
2025-11-06 22:38:58.147 [Info]  Configuring code indexing for 'e:/Subfolder'
2025-11-06 22:38:58.149 [Warn]  Could not configure code indexing until an active project is set

[jacobwhite77888]

Yeah, that’s definitely a frustrating issue especially for anyone who structures their projects with multiple subfolders. It sounds like STM32Cube for VS Code isn’t handling relative paths or project discovery correctly when the workspace isn’t at the root level. I’ve run into similar problems with other extensions that assume a flat project layout. The workaround you mentioned makes sense, but as you said, it breaks Git integration and history, which is far from ideal. Hopefully, ST will address this in an upcoming update, since multi-project repositories are pretty common, and having to restructure everything just to make the extension happy isn’t practical.