Improvement suggestions for CMake files generated by STM32CubeMX

[Erlkoenig]

Hi,

I have three small suggestions to improve the CMake build system generated by STM32CubeMX to be used by VS Code to fix some annoyances.

1.

In cmake/stm32cubemx/CMakeLists.txt, use

set(TOOLCHAIN_LINK_LIBRARIES "-lm")

instead of

set(TOOLCHAIN_LINK_LIBRARIES "m")

This way CMake knows that the "m" library is an external one. When the user sets

set(CMAKE_LINK_LIBRARIES_ONLY_TARGETS ON)

in the "CMakeLists.txt" in order to help finding issues in complex project setups, the old behaviour causes a CMake error as there is no explicit "m" target, but with "-lm" CMake is happy. Being able to use "CMAKE_LINK_LIBRARIES_ONLY_TARGETS" is desirable as it helps finding typos easily when many targets/components are defined across many individual CMake files.

2.

In cmake/stm32cubemx/CMakeLists.txt, use

target_link_libraries(${CMAKE_PROJECT_NAME} PRIVATE ${MX_LINK_LIBS})

instead of

target_link_libraries(${CMAKE_PROJECT_NAME} ${MX_LINK_LIBS})

i.e. use the explicit syntax. When the user wants to refer to additional targets later, the old behaviour makes it impossible to set PUBLIC/PRIVATE as CMake complains about mixed usage, but with this change the user is free to choose PUBLIC/PRIVATE. Making the scope explicit is also more clear.

3.

In "cmake/gcc-arm-none-eabi.cmake", use

set(CMAKE_C_FLAGS_RELEASE "-Os -g3")
set(CMAKE_CXX_FLAGS_RELEASE "-Os -g3")

instead of

set(CMAKE_C_FLAGS_RELEASE "-Os -g0")
set(CMAKE_CXX_FLAGS_RELEASE "-Os -g0")

i.e. always generate debug information, including for release builds. 

There is no real advantage in not generating the debug information, as it only resides within the .elf file but of course is never flashed to the target. So using "-g0" instead of "-g3" only saves a few megabytes of HDD space and has no further advantages.

For me it is frequently necessary to debug "Release" builds as the timing behaviour of a "Debug" build differs or the "Debug" image is simply too big/slow. Of course debugging an optimized "Release" build is more difficult, but it's still much better with debug information than without. When examining a crash dump/log post-mortem, having debug information within the ELF file is extremely helpful; that's also why I archive the ELF files (and not just BIN/HEX) of applications used for production.

Also, debug information can always later be removed if necessary using "strip" or "objcopy" (e.g. as a custom CMake command if needed), but not re-generated.

Thanks and Regards!

[Souhaib MAZHOUD]

Hello @Erlkoenig 

Your contribution is greatly appreciated!

I will share these points with dedicated team for review.

KR, Souhaib

[unsigned_char_array]

Additionally I have a few suggestions too:

1: When changing the compiler the generated CMakeLists.txt file of TouchGFX has to change to change the path to libtouchgfx. Build systems such as cmake should be compiler independent. Instead of having to regenerate this file it would be better if there was a conditional switch based on compiler instead of having library hardcoded in the CMakeLists.txt file. It's fine if the MCU type remains fixed as that should not change for a project.
More information here:
https://community.st.com/t5/stm32cubeide-for-visual-studio/changing-toolchain-by-running-project-setup-again-fails/m-p/859262/highlight/true#M1530

2: I needed to modify cmake\starm-clang.cmake in order to make clang-tidy work:
https://community.st.com/t5/stm32cubeide-for-visual-studio/clang-tidy-fails-to-process-project/m-p/855043/highlight/true#M1472
This is probably because ST's version of clang compiler is modified and has some shortcuts. But these same shortcuts are not present in clang-tidy. Alternatively ST could provide a patched version of clang-tidy. Either way it doesn't work out of the box and access to tools like clang-tidy is a main reason for us to switch from GCC to Clang.

3: Not a suggestion. You might also take a look at this topic I customized the root CMakeLists.txt file to add/remove sources/defines. Can be helpful as an example. I find CMake not the most intuitive to use so examples are greatly appreciated. https://community.st.com/t5/stm32cubemx-mcus/how-to-customize-your-stm32cubemx-generated-cmake-project/td-p/857290

[Erlkoenig]

Thanks Souhaib & unsigned_char_array!

I just remembered another issue:

For the STM32WL, STM32CubeMX generates just

set(TARGET_FLAGS "-mcpu=cortex-m4 ")

in the cmake/gcc-arm-none-eabi.cmake which makes the compiler by default assume that the MCU has an FPU, which it doesn't. Instead it should be

set(TARGET_FLAGS "-mcpu=cortex-m4 -mfloat-abi=soft")

Additionally it would be nice to have the option to not use the FPU on the MCUs that do have it (i.e. all other Cortex-M4 STM32?), i.e. have an option in STM32CubeMX to output -mfloat-abi=soft. This can be useful to develop/test/profile code for the STM32WL on another MCU with representative execution speed.