STM32CubeMX/VSC Feature Request: Import Libraries as Git Submodules

BMcDo.3 · ‎2025-05-28

STMCubeMX has various methods of copying parts or all of the libraries to a project, or referencing them outside of the project. But I've not yet seen it do what is IMO the most maintainable method: including the libraries as git submodules. You've already got them up on GitHub, and you're using submodules within the libraries (e.g. STM32CubeF4). Can you close the loop, and add support in your tooling for us to use them in our projects, as submodules?

Preferably usable with CMake and your VSCode extension.

Thanks for your consideration.

Nawres GHARBI · ‎2025-05-30

hi @BMcDo.3

good idea will share it with the dev and management team

Kraal · ‎2025-05-30

I would like this as well please.

Pavel A. · ‎2025-06-01

Looks like a good idea at first glance... but how do you think it can be done? A C/C++ project (the main product of Cube) has no notion of repositories or submodules. A project only refers to filesystem (or Eclipse "virtual filesystem") paths. So these git submodules should be mapped to concrete filesystem paths; this will impose changes of the project tree structure and the "library manager" repo structure. Some users would be upset or unable to use the proposed feature.

I'd like to have the following (and already do this manually for my customers' projects) :

* Cube should make use of path macros to point to library locations: HAL drivers path, CMSIS path, FreeRTOS path etc. The concrete form of "path macros" depends on the type of created projects. For Eclipse they will be "build variables", for makefiles and Cmake - their native variables. For Keil and IAR - whatever works there. Users will be able to edit these variables, thus easily redirect the library locations as they want.

* Cube should be able to download and install parts of the firmware libraries from their git repos on github, but it will be up to the users to map the local work copy paths to their project repository - as submodules or symlinks or whatever they want.

BMcDo.3 · ‎2025-06-01

@Pavel A. wrote:
Looks like a good idea at first glance... but how do you think it can be done? A C/C++ project (the main product of Cube) has no notion of repositories or submodules. A project only refers to filesystem (or Eclipse "virtual filesystem") paths.

The file/folder tree structure for the libraries created by cloning e.g. STM32CubeF4 from GitHub and updating its git submodules is the same as is created by the STM32CubeMX Code Generator. (The CubeMX generator would maybe need to push the library contents down one level, probably into a folder named after the (meta)lib, e.g. "STM32CubeF4".)

In my idea here, when a user chooses it, the project generated by CubeMX would be defined by the contents of the CMakeLists.txt files. ST could add CMakeLists.txt files in the Cube libraries (and submodules), so that they can be included in the build via `add_subdirectory()` from the project-level CMakeLists.txt. Or maybe there's another way to do it.

I currently have a project where I forked STM32CubeF4 from GitHub, added CMakeLists.txt as needed, and deleted most of the subdirs/submodules I'm not using (Projects/, and board-level drivers under Drivers/BSP/ (all except Components/)).

@Pavel A. wrote:
So these git submodules should be mapped to concrete filesystem paths; this will impose changes of the project tree structure and the "library manager" repo structure.

I'm proposing a new option for "Toolchain / IDE" selection. How would that affect anyone's existing projects, or prevent them from using anything?

@Pavel A. wrote:
I'd like to have the following (and already do this manually for my customers' projects) :
* Cube should make use of path macros to point to library locations: HAL drivers path, CMSIS path, FreeRTOS path etc. The concrete form of "path macros" depends on the type of created projects. For Eclipse they will be "build variables", for makefiles and Cmake - their native variables. For Keil and IAR - whatever works there. Users will be able to edit these variables, thus easily redirect the library locations as they want.
* Cube should be able to download and install parts of the firmware libraries from their git repos on github, but it will be up to the users to map the local work copy paths to their project repository - as submodules or symlinks or whatever they want.

Your first bullet sounds like a separate potential feature request?

Pavel A. · ‎2025-06-02

> I'm proposing a new option for "Toolchain / IDE" selection.

Which option? a new type of CMake project?

> Your first bullet sounds like a separate potential feature request?

Yes, you're right.

BMcDo.3 · ‎2025-06-02

@Pavel A. wrote:
> I'm proposing a new option for "Toolchain / IDE" selection.
Which option? a new type of CMake project?

Oh, I see later versions of CubeMX have a CMake option in the pulldown (contrary to my screenshot). I'm in the process of updating our project to use later CubeMX and libs...

Maybe the implementation of my idea here would include an option to clone the Cube lib repos instead of copying files. Or maybe it would be a tweak to how the CMake project type works? I think it still would require adding CMakeLists.txt files to the Cube libs (including their submodules).