CubeMX 6.14.xx breaks CMake workflows
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.