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

[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

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

[Tizio1234]

Thx, I'll look into it tomorrow.

[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