2025-05-07 3:53 PM
Really appreciate updates for using proper OBJECT versus INTERFACE library type, but using CMAKE_SOURCE_DIR and CMAKE_PROJECT_NAME have very specific meaning and disallow the ability to utilize a CubeMX project in normal CMake projects. These both refer to the top level entry point of the CMake project. This breaks if there's a container project for build automation.
These instances appear in both the gcc-arm-none-eabi.cmake and stm32cubemx/CMakeLists.txt - the previous instance in the toolchain definition wasn't problematic as the instances could be updated. Unfortunately, CubeMX does not respect customizations to stm32cubemx/CMakeLists.txt -- the file is lost after any automatic generation. This breaks CubeMX for easy edits if there's a need to maintain the previous behavior.
PROJECT_SOURCE_DIR should be compatible and reference the proper files without breaking previous behavior (allow sub-directory CMake use and not impact the original). Would really like if there was a settable variable for this and that the "Add necessary library files as reference in the toolchain project configuration file" worked by setting the variable in the top-level / user modifiable CMake and then using that instead of hardcoded paths. Consider owning the STM32CUBEMX_ variable namespace and allowing these things to be customized! Target suffixes would be helpful as well to allow multi-firmware builds.
Our current workaround is likely to move away from CubeMX and instead rely on manually generated CMake and LD scripts.
2025-05-08 1:18 AM
Hello @amulbrook
First let me thank you for posting.
I'm currently investigating this issue.
I 'will get back to you asap.
THX
Ghofrane
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-05-08 2:42 AM
Hello @amulbrook
Regarding the first point : ${CMAKE_SOURCE_DIR} variable
A ticket has been raised to development team :internal ticket number 206627
Regarding the change request "Consider owning the STM32CUBEMX_ variable namespace and allowing these things to be customized! Target suffixes would be helpful as well to allow multi-firmware builds."
A ticket has been raised to development team :internal ticket number 209315
I will keep you posted with updates.
THX
Ghofrane
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.