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

[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).

[mattias norlander]

---

@Stephen_PP wrote:

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

---

The idea was to have "separation of concern" between CMake files managed by MX vs what CMake-files you develop as part of your project... This can of course be challenged. But if this request is only because our first CMake structure has some bugs, then I think it is better to try to fix those bugs.

But if you can describe some use cases (beyond INTERFACE bug) where you need to modify what MX generates in terms of CMake-files, then please share your thoughts. We are eager to improve.

 

---

@Stephen_PP wrote:

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

---

Will bug report this! Ticket number: 199761

[mattias norlander]

Hi guys, @ANauz.1 , @Tizio1234 , @Dirk_Castelijns , @Stephen_PP 

Here is a proposal of an update CMake structure coming from MX.
This is not yet implemented in MX, it is hand-written for the purpose of trying to quickly collect feedback from all people in this thread:

• stm32cubemx is kept as interface library for macros and include paths.
• Static libraries are created for each driver module: HL/LL driver, middlewares, x-cube, etc, …
• Those libraries inherit macros and include paths from stm32cubemx interface library.
• Application files (main.c, stm32xx_it.c, startup…) are added directly to the project as source files.

The attached project is a bit quick&dirty. The purpose of it is to kick-start a discussion and to make quick progress!

Please share thoughts, questions, remarks!

 

Kind regards, Mattias

[Tizio1234]

Thx, I'll look into it tomorrow.

[Stephen_PP]

The request for the USER section is indeed to attempt to fix bugs with the cmake structure.

I suppose i have a few other changes:
Methodology:
I ran a compilation of a project which was created in the STM32CubeIDE (non-Cmake)[this project performed as expected], and checked it against a build done with a project created from the Cmake-Generator in STM32CubeMX.
In doing this comparison, i looked at all statements for all steps (assembler, compiler, linker) and modified the .cmake file (generated by the STM32CubeMX) so that the build commands were identical to the build commands from the STM32CubeIDE project.

Here is a screenshot of a Diff between what the current CubeMX generates in the .cmake file (left) and what I believe is the more correct implementation(Right).

 

Issues:

CMAKE_C_FLAGS are used for both Linker AND Compiler; Flags for the Assembler should not be included here.

Optimization flags are being placed in the CMAKE_C_FLAGS depending on the CMAKE_BUILD_TYPE - Why do that when cmake provides flags for specific configurations (e.g. CMAKE_C_FLAGS_DEBUG, CMAKE_C_FLAGS_RELEASE, etc.).

Some flags are being included in build steps that don't need them - the optimization flags (e.g. -Og) does not need to be included in the Assembler --- the TARGET_FLAGS do not need to be included in the Linker.

Right now, with just `-Wall` flag, i am getting compilation warnings for MX-Generated/Supplied code - I want a way to turn off compiler warnings for just the MX-generated code (this is difficult right now since the MX-Generated cmake includes the -Wextra and -Wpedantic flags) which i cannot do unless i modify the .cmake file.

Request:
It would be awesome if the STM32CubeMx could use information from a .cproject file to populate things like optimization and other build flags.  Really this is what bothers me, since i cannot export my existing STM32CubeIde project to a CMake project and the .cproject contains much of the project-specific information.  (I realize this may be outside your area)


Please Note:  Some of these things i've mentioned may be fixable with the current cmake structure;  However I am unable to figure out how to do so.

[ANauz.1]

Hello @mattias norlander 

Sorry I do not have much time this days to have a look at this new feature (working on a project that is no more at a CubeMX phase)

But from a very quick test I made:

• It seems that having specific compilation definitions/options in the user libs do not affect the compilation of stm32cubemx (and that is a good thing :) )
• I do not see multiple compilation of the same files in the interface (another good thing)

It was 2 important point I mentioned in my first post. So for me this new structure seems a good improvement compare to the first one.

Thank

Antoine