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

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]

@Cartu38 OpenDev,

I believe that in my custom project, keeping the schematic and the firmware in the same repo is almost a must-have because they are very closely related: there's a limited amount of changes you can do to one without affecting the other. Thus using a single repository makes sense.

As for the non-existing GUI things are not as straightforward. I know that if I wanted to use CMake as a build tool there I could put it in a different repo, and utilize VSCode's workspaces to work on both the firmware/schematic and the GUI project at the same time. This approach also allows putting independent "launch.json" files in both repos to facilitate debugging and flashing a newer version.

Since this specific project is supposed to act as a "showcase on embedded development" (albeit the schematic, the firmware and the GUI will not be "complex" by any modern standard) then keeping all three aspects in the same repository makes sense. For anyone willing to check it out cloning one repo is quite easy.

If you work on a larger project which involves, say, two microcontrollers from two different manufacturers using two separate toolchains then things get more complex. VS Code's workspaces approach works marvelously well there, and although I haven't tried it I believe ST's extension should work properly well, judging form what @vincent_grenet said in the other post.

Thus it may be "just me" who is having a problem with the extension...

[Pavel A.]

"Add project(s) as single workspace folder instead" - what is the meaning of that exactly? Something that the user should do or the extension is about to do?

[vincent_grenet]

@Pavel A. 

The suggestion to "Add project(s) as a single workspace folder instead" is kindly advising you to use multiple "Add Folder to Workspace" actions, resulting in a multi-root workspace. This approach is recommended when you have multiple top-level CMakeLists.txt projects, rather than adding a single top-level root folder of the entire file system.

To clarify, referring back to @ankes - Thanks for sharing - example: https://github.com/anttikes/usb-fm-radio/tree/cmake-test, the advice is to add two folders to the workspace separately—one for the Firmware project and one for the GUI project. These are independent projects from a CMake perspective.

However, if you use the single top-level CMakeLists.txt approach as in https://github.com/anttikes/usb-fm-radio/tree/cmake-test-in-root, where Firmware and GUI are subdirectories of the same project, then adding just one folder to the workspace is appropriate and no warning will appear.

In summary, this notification is a helpful suggestion to guide you towards the current best practice. We remain open-minded and encourage feedback, as we are working on improving support for multi-context projects (e.g., multicore, TrustZone, application & bootloader).

[ankes]

@vincent_grenet,

For the sake of an exercise I created three more repositories:

• https://github.com/anttikes/stm32-extension-project-A
• https://github.com/anttikes/stm32-extension-project-B
• https://github.com/anttikes/stm32-extension-project-combined

A and B are both independent projects with a root-level CMakeLists.txt. I can clone either, open VS Code, and the extension works smoothly. I can also add both folders to the same workspace, and things continue to work, although I have to switch between folders in CMake. A uses GNU compiler and B uses ST's clang with "newlib" library. Both projects were generated with MX 6.15.

The "Combined" uses submodules to bring projects A and B in. If I clone this repo and open VS Code, the extension breaks. It doesn't add "cube-cmake" to the PATH, and thus no matter if I choose project A or project B the CMake's configure step fails. If I open a code file, it doesn't start clangd.

In my opinion, the extension should work correctly with the "Combined" repo. You are free to use these demo repositories when diagnosing and fixing the issue.

Let me know when these repositories are no longer needed so I can delete them.

I will remove the "cmake-test" branches from my real repository because they relied on a "non-existing project" and some creative thinking. This new example is "developer-proof" =)