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!
