BUG: STM32CubeMX should not create an INTERFACE library when CMake selected

[ANauz.1]

Hello 

After some work with STM32CubeMX CMake generation and discussions with good CMake user, I really think that, when generating a projet with STM32CubeMX, it should not be an INTERFACE library (or at least not only that)

As a CMake user said to me, the purpose of INTERFACE library is the following:

When a target represents some collection of requirements that doesn’t involve an actual library file. For example, a collection of flags or includes.

The main problems I have when using the current CMake generation:

• I'm linking several libs to the project. They have to be linked to the stm32cubemx lib to have µC and #define defined. Every lib compilation involve a stm32cubemx lib compilation.
• I want to change some compilation flag in my lib. For example, level up somes warnings to errors such as implicit conversion or unused parameters. As the stm32cubemx is an interface, when it is compiled, it "takes" the compilation flag of the linking lib. As a result, errors compilation rise because there are warning in stm32cubemx lib

For me, STM32CubeMX CMake generated project should be more like that:

• A main CMakeLists.txt creating an executable
  • This executable should add the core sources (main.c, gpio.c, ...)
  • As now, it should allow to link libs, add compile_definition...
• A CMakeLists.txt creating a non INTERFACE library, containing all the Drivers/STM32...._HAL_Driver/Src
• A CMakeLists.txt creating an INTERFACE library containing the #define, compilation flags, µC informations. It could be included in the previous file.

Integrating CMake project generation in STM32CubeMX is really a good idea. For me it is really a major improvement of the Cube suite. But for now it is not usable without some modifications.

I would be really happy to talk of the subject with ST employees and to see (some of) those modifications integrated in the next STM32CubeMX.

Regards

Antoine

[Imen.D]

Hello @ANauz.1 ,

Thank you for having reported the point.

Your request is escalated internally to our team to be analyzed through ticket number: 184662.

We will be back to you as soon as possible.

(PS: ticket number 184662 is an internal tracking number and is not accessible outside of ST)

[Tizio1234]

Same issue here! It's really frustrating, for now I've come up with this workaround, for everyone new to this issue/problem.

https://community.st.com/t5/stm32cubemx-mcus/stm32cubemx-cmake-code-generation/td-p/688678

[ANauz.1]

Hello @Imen.D 

Is there any news on this topics?

Regards

[mattias norlander]

Hi @ANauz.1 ,

---

@ANauz.1 wrote:

Is there any news on this topics? 

Yes - there is news. We had meeting on this topic 2 weeks ago. We agree with the pain points you describe and will try to fix that. Maybe we can upload a fixed CMake structure here as a preview to get your feedback on it?! Early feedback is always good!

One challenge that requires a bit of extra analysis is to try to not break compatibility vs existing MX versions with CMake. We have ideas on how to achieve that, but I am not sure we are happy with that solution...

You next question is probably, when can we fix this? Currently checking whether it can fit in the November release. But we are soon already in code freeze. Next release window would be end of 2025-Q1. :(

[ANauz.1]

Hello,

It's great news you can work on the subject.

I would be happy by giving you a feedback on a new CMake structure. I could also show it to my team so we could give you our feedback.

Regards

[mattias norlander]

Excellent - much appreciated. :- )
Generally speaking, we should strive for closer collaboration with our awesome user base, to show "POCs" and collect feedback. Means you get what you want, and less risk we invest in the wrong directions.

Currently 2025-Q1 looks most realistic. TBC.

[Dirk_Castelijns]

Hi Mattias,

Good to see that STM32CubeMX CMake integration becomes better and better. Providing the stm32 generated stuff in a separate library is a good approach. As I spent quite some time with CMake and STM32 development myself, I have a few pointers for you (which you might have figured out yourself already).

I would suggest to provide the stm32cubemx library as an OBJECT library instead of INTERFACE. This will prevent unnecessary compilations of the same source file for each depending CMake target. Using STATIC will anyway be NOT a good idea because for some reason the linker is then not able to handle WEAK symbols correctly or figure out where the entry point (Reset_Handler) implementation is.

With target_compile_definitions() and target_include_directories() you can then use PUBLIC instead of INTERFACE.

Regards,

Dirk

[Stephen_PP]

Just started using the CMake export here and am experiencing the same issues.

A relatively low-effort improvement (from the ST side) is to add USER sections to the CMAKE files for when they are generated; same system that already exists for the source files (e.g. main.c).
This would at least allow us to try to workaround the generated CMake code without our changes getting wiped out every time the code is generated.

I was really hopeful that the November release of the CubeMx was going to address some of these pain points; unfortunately I was disappointed.

Not to mention that the CubeMx is using a Linker generation script from 2019, even though there is a perfectly up-to-date generation script being used in the CubeIde...
And additional issues, like unsupported/old CMAKE flags from old versions of cmake instead of up-to-date flags.  (e.g. using CMAKE_C_LINK_FLAGS instead of CMAKE_EXE_LINKER_FLAGS).