mixed relative and absolute paths in generated project files
Using "Firmware Relative Path" and generate code with references f STM32CubeIDE will mix relative and absolute paths in generated project files
STM32CubeMX 6.14.0 on Windows 11.
1. Create a directory and unzip en.stm32cubeh5-v1-5-0.zip there
1. Create a minimalistic new project in STM32CubeMX for STM32H5.
2. In tab Project Manager, tab Project:
2.1 Set Project Location to the created directory and set the name of your project
2.2 Set Toolchain / IDE to STM32CubeIDE
2.3 Uncheck Use Default Firmware Location
2.4 Use the browse button and select STM32Cube_FW_H5_V1.5.0 in the directory.
3. In tab Project Manager, tab Code generator: choose option Add necessary library files as reference in the toolchain project configuration file
4. Save the project and generate the code.
Note that the path is correctly stored as a relative path in the .ioc-file with the key ProjectManager.CustomerFirmwarePackage
Bugs
Despite that the actual relative path from Toolchain Folder Location is ..\STM32Cube_FW_H5_V1.5.0, the UI always show the resolved absolute path. This is confusing as it is hard to understand if you have selected the correct path that will also survive if the whole created directory is committed to VCS.
This should really be changed to show a relative path to toolchain folder and the labels should clarify that the toolchain folder is the base.
In the generated STM32CubeIDE project, the .project will use expected relative paths, e.g.
<linkedResources>
<link>
<name>Drivers/STM32H5xx_HAL_Driver/stm32h5xx_hal.c</name>
<type>1</type>
<locationURI>PARENT-1-PROJECT_LOC/STM32Cube_FW_H5_V1.5.0/Drivers/STM32H5xx_HAL_Driver/Src/stm32h5xx_hal.c</locationURI>
</link>But in .cproject, the include paths will be recorded as absolute paths which means that the project cannot be shared with another developer unless s/he puts the project in the exact same location, e.g.
<option id="com.st.stm32cube.ide.mcu.gnu.managedbuild.option.defaults.1522202762" name="Defaults" superClass="com.st.stm32cube.ide.mcu.gnu.managedbuild.option.defaults" value="com.st.stm32cube.ide.common.services.build.inputs.revA.1.0.6 || Debug || true || Executable || com.st.stm32cube.ide.mcu.gnu.managedbuild.option.toolchain.value.workspace || STM32H563RITx || 0 || 0 || arm-none-eabi- || ${gnu_tools_for_stm32_compiler_path} || ../Core/Inc | C:/[REDACTED]/STM32Cube_FW_H5_V1.5.0/Drivers/STM32H5xx_HAL_Driver/Inc | C:/[REDACTED]/STM32Cube_FW_H5_V1.5.0/Drivers/STM32H5xx_HAL_Driver/Inc/Legacy | C:/[REDACTED]/STM32Cube_FW_H5_V1.5.0/Drivers/CMSIS/Device/ST/STM32H5xx/Include | C:/[REDACTED]/STM32Cube_FW_H5_V1.5.0/Drivers/CMSIS/Include || || || USE_HAL_DRIVER | STM32H563xx || || Drivers | Core/Startup | Core || || || ${workspace_loc:/${ProjName}/STM32H563RITX_FLASH.ld} || true || NonSecure || || secure_nsclib.o || || None || || || " valueType="string"/>Absolut paths also end up in .mxproject but using \ as path separator instead of /. I am not sure what this file is actually used for.
My intended use case was to have developers share both the actual product projects and a common controlled copy of ST HAL and middleware code, without requiring everyone to have the ST code at the exact same place in their local filesystem - we all know that such a requirement doesn't scale past 2 developers in the same room.
But with the bugs above, the option Add necessary library files as reference in the toolchain project configuration file cannot be used for that.
Best regards, Jesper