2024-06-19 02:24 AM - edited 2024-06-20 12:34 AM
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:
For me, STM32CubeMX CMake generated project should be more like that:
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
2024-06-20 08:04 AM
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)
2024-06-22 04:55 AM - edited 2024-06-22 04:56 AM
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
2024-09-09 02:26 AM
2024-09-17 11:19 PM
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. :(
2024-09-18 12:25 AM
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
2024-09-18 02:39 AM - edited 2024-09-18 02:39 AM
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.
2024-11-18 04:38 AM - edited 2024-11-21 12:12 AM
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