Skip to main content
Associate II
July 8, 2026
Question

Followup - Organising CMake folder structure in CubeMX generated code

  • July 8, 2026
  • 0 replies
  • 54 views

This is a followup to the question: How to organize the folder structure in CubeMX-generated code

There, the solution was by ​@Ghofrane GSOURI and the added comment by ​@Andrew Neil to keep your application code outside of CubeMX generated folders in structure like so:

Project/
├─ Core/ # CubeMX-owned
│ ├─ Inc/
│ └─ Src/
├─ Drivers/ # ST/CMSIS
├─ Middlewares/ # Optional (FreeRTOS, USB, etc.)
├─ App/ # Your application logic
│ ├─ Inc/
│ └─ Src/
└─ Framework/ # Your reusable firmware framework
├─ Inc/
└─ Src/

Which make a ton of sense, but I am stuck at how to actually implement this in CMake. I let CubeMX generate a folder for CMake toolchain. That directory has these additional files/folder:

Project/
├── Application ## directories where my code would exist
│   └── blinky
│   └── blinky.c
│   ├── blinky.h
│   └── uart/
│   └── ...
├── cmake
│   ├── gcc-arm-none-eabi.cmake
│   ├── starm-clang.cmake
│   └── stm32cubemx
│   └── CMakeLists.txt
├── CMakeLists.txt
├── CMakePresets.json
└── Core/..., Drivers/...

All the CubeMX generated sources are listed in `cmake/stm32cubemx/CMakeLists.txt` which links everything to `${CMAKE_PROJECT_NAME}`. `${CMAKE_PROJECT_NAME}` is also the executable generated by the top level `CMakeLists.txt`. I am not sure how to add new executables to CMakeLists.txt, and how to to be able to `#include <main.h>` inside files in `Application/`

I tired to solve this with AI, but the end result was that I was not able to build due to for example blinky.c not knowing where/what main.h is. Maybe I do not know how to use CMakeLists and AI properly. Would love some direction from someone who has accomplished this.

 

Cheers,

Shrinivas