cancel
Showing results for 
Search instead for 
Did you mean: 

mixed relative and absolute paths in generated project files

JesperEC
Associate III

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

 

2 REPLIES 2
Pavel A.
Evangelist III

 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.

So users are encouraged to choose locations that are OK for their build environments and VCS. This is possible, not  just for two folks in a room.

Think "convention over configuration".

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.

We don't save .mxproject files in VCS. Haven't seen any problem.

But with the bugs above, the option Add necessary library files as reference in the toolchain project configuration file cannot be used for that.

Again, convention over configuration plus some cheap tricks (symbolic links exist on Windows too) - and this works. 

'Do not panic!"