"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.

[vincent_grenet]

Dear community members,
Thank you for reporting and sharing all this valuable information.

I confirm that we are working on multi-project repositories, which raises many questions and options to find the best approach. I would greatly appreciate hearing your wishes and local practices here.

Based on your previous comments, if it’s not possible to share a full project, could you please share a schematic of your project structure? Mainly, highlight the folder organization and where the CMakeLists.txt files are located. Also, please explain how you add this project structure into VSCode (e.g., do you add the top-level folder to the workspace or rely on multiple folders added separately, creating a multi-root workspace?).

Thank you in advance. Your input will help us support you better!

[ankes]

I have published to my own repository several examples which likely exhibit the most common project patterns. When cloning any of the repositories linked in this post, include the submodules. Especially the "tinyusb" submodule contains a lot of CMakeLists.txt files which will easily confuse any autodetection mechanisms. CMake Tools extension is smart enough to ask which one it should use.

The https://github.com/anttikes/usb-fm-radio/tree/cmake-test branch presents what I consider likely to be the most common approach. Each subfolder holds its own project, and they are independent of each other. Switching between them in VSCode happens by manually adjusting the "cmake.sourcesDirectory" setting.

Note that the "GUI" subfolder is not present yet in the repo since I have not progressed this far. If I had, it would be there, and it would contain a CMakeLists.txt of its own.

In this branch, the STM32CubeIDE extension itself does not work correctly. It just says "Could not configure code indexing until active project is set", and things like "Setup STM32Cube project(s)" are grayed out. CLangd file is not generated or maintained, and overall the experience is rather poor. I believe that if the ST's extension were to follow "cmake.sourcesDirectory" then things would be much, much better.

The https://github.com/anttikes/usb-fm-radio/tree/cmake-test-in-root branch presents yet another example.

In this approach, the root folder of the repository contains a CMakeLists.txt file which then adds the "firmware" and the still-missing "GUI" subfolders, using CMake's own semantics. In this repository, the STM32CubeIDE extension works correctly, and maintains the CLangd file as expected. However, if I were to run the STM32CubeMX's code generation on the IOC file then things would break down. Horribly.

I believe this second approach is not that viable, mainly due to the fact that if "GUI" were to have submodules those modules would be defined at the root of the repository, and be kind-of shared between two independent disciplines.

I hope these two examples will shed some light on how I would see this extension used. In my opinion, the first example is likely the most prevalent, with independent projects all around, and manually adjusting the "cmake.sourcesDirectory" to choose which project you want to work on. The second approach can also be considered, and might be used in scenarios where a developer needs to build the entire thing in one go, and switch between debugging the firmware, and debugging a GUI application quickly. A ".vscode" folder with a suitable "launch.json" would definitively do the trick.

I have not included the third imaginable option which is the VS Code's "workspaces" approach. In this approach, there'd be a "workspace file" in the root folder of the repository, which would then include "Firmware" and "GUI" as kind-of independent projects. I believe this approach would not work for me since the "submodules" of the Firmware project are listed in the root of the repository, and if "GUI" were to have submodules of its own things would get very, very messy.

Also, one final point: neither the extension, nor STM32CubeIDE itself works correctly when HAL, CMSIS etc are provided via submodules. You can build the projects, sure, but any code generation will royally mess things up. Maybe allowing the developer to specify which folder contains the HAL or CMSIS headers is required?

[Cartu38 OpenDev]

@ankes Thanks for sharing but not sure fully get all your points here.
Cloning https://github.com/anttikes/usb-fm-radio/tree/cmake-test works for me. I'm able to build your project.

Only 2 notes:

• I'd to hack a bit your CmakeLists.txt to get it portable
  
• I've added "Firmware" folder to VSCode workspace (not your git repo root because not CMakelists.txt at root of)
  

Doing all such I'm build success and prior STM32CubeiDE for Visual Studio Code is able to act as expected.
As example project setup is available

I'll look at your second sharing https://github.com/anttikes/usb-fm-radio/tree/cmake-test-in-root

[ankes]

Thanks for checking it out, @Cartu38 OpenDev.

Like explained, "cmake-test" branch is a scenario where the two projects, "Firmware" and the-still-unexisting "GUI" are independent in the sense that the developer would use VS Code's "CMake: Select Active Folder" command to change between the two. I provided it as a courtesy to @vincent_grenet in hopes that it might help them in choosing how to develop the extension further.

The key point of my entire post is to point out that the STM32Cube extension itself does not properly support a scenario where such "independence" exists. I am aware that declaring a VS Code workspace would solve the matter. Also, like shown in "cmake-test-in-root" (and also currently in "main") it is possible to utilize an alternative approach to make the extension work.

The punchline is if you need to create a workspace or fiddle with file locations in order to make an extension work then the extension obviously has a problem.

[Cartu38 OpenDev]

@ankes
Ok about  "Firmware" and the-still-unexisting "GUI" what I'm unable to catch is: what is issue to rely on multi workspace roots as you confirm this will work ?

[Cartu38 OpenDev]

@ankes 
Looking at https://github.com/anttikes/usb-fm-radio/tree/cmake-test-in-root ok I got it. Very same than https://github.com/anttikes/usb-fm-radio/tree/cmake-test  adding as extra a top most CMakeLists.txt file.
Sounds like you intention is more to get a single project despite the 2 sub projects - if we may call them like this - may be independent. I guess it helps you to get CMake Tools usage easier allowing to build them all at once.
Right the stuff breaks because duplicate sub directory references but no MX fault, just you cannot concatenate these two independent projects without a bit of minor updates. The same doing this I'm able to build success.

Managing commonalities between your 2 projects Thanks git submodules or ... is too according to me your duty. I'm thinking we cannot ask anything to ST here. Each end user as its own taste / way or working.

Feel free to comment I like this topic kind, looking myself for best way to deal with code reuse, project structure.

[Pavel A.]

But the extension can at least detect that there's no cmakelists.txt in the root folder and warn ?

 

[vincent_grenet]

@Pavel A. 

We approach this from a dual perspective. Our rationale is that VS Code is an open ecosystem, and the CMake Tools extension is highly popular. Furthermore, not all end users are solely dedicated to STM32 application development.

For this reason, when the CMake Tools extension detects a CMake project, we prompt the user with an option to enrich it as an STM32Cube project. We cannot force this enhancement, and we anticipate that automatically warning users about the absence of a CMakeLists.txt file at the project root would be disruptive or cumbersome for a significant portion of our user base.

Once STM32Cube project granted we may already promote some information like.

[ankes]

@vincent_grenet,

Now that I managed to get started with the "GUI" side of my project I have to say that workspaces with two separate folders is the only way forward for me.

The underlying reason, suprisingly, has nothing to do with the extension but more about CMake itself: it does not allow a setup where you use two different C++ compilers inside one CMakeLists.txt. Since the firmware portion is built by an ARM GCC compiler and the GUI portion uses x86_64 LLVM then I need to use two separate CMakeLists in two different folders.

The ordinary "CMake Tools" extension is able to handle this just fine but "STM32Cube CMake Support" extension throws fits when it encounters this situation.

Since the x86_64 LLVM cannot be installed by the "STM32Cube Bundles Manager" (for obvious reasons) then I will  probably need to ditch it as well, and just install STM32CubeMLT manually.

It is rather unfortunate that for example the "STM32Cube Debug Core" relies on "STM32Cube CMake Support" although logically the former should only require "STM32Cube Core" to install the "cube cli" and through it the binaries required to operate the ST-provided gdb variant.