STM32CubeIDE uses relative paths when linking to firmware at an absolute path

[Miles1]

When creating projects, I prefer to link to common library files, rather than copy them into my project, but how the IDE manages these relative links makes it difficult to share projects among developers via version control. Note that this configuration option can be found in "Code Generator Options > Add necessary library files as reference in the toolchain project configuration file" when creating a project.

There are two scenarios with different challenges:

• Default, user-dependent fw path: "~/STM32Cube/Repository/", e.g. "/home/miles/STM32Cube/Repository/"
• Custom, user-independent fw path: "/usr/share/stm_repo"

For reference, these paths are configurable in "Window > Preferences > STM32Cube > Firmware Updater > Repository Setup".

Default path scenario:

These paths appear as follows in .project:

        <link>
            <name>Drivers/STM32F4xx_HAL_Driver/stm32f4xx_hal.c</name>    
            <type>1</type>    
            <locationURI>$%7BPARENT-5-PROJECT_LOC%7D/STM32Cube/Repository/STM32Cube_FW_F4_V1.25.1/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c</locationURI>    
        </link>

It's understandable to use relative paths in this case, since you don't want any developer names in absolute paths to their home directory. Unfortunately, this means that if another developer clones the project repo, their workspace must be at the same depth relative to their home directory as their teammates.

Custom, user-independent path scenario:

These paths appear as follows in .project:

        <link>
            <name>Drivers/STM32F4xx_HAL_Driver/stm32f4xx_hal.c</name>    
            <type>1</type>    
            <locationURI>$%7BPARENT-7-PROJECT_LOC%7D/usr/share/stm_repo/STM32Cube_FW_F4_V1.25.1/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c</locationURI>    
        </link>

Including the PARENT-n-PROJECT_LOC prefix in this case breaks the build for any developer that clones to a directory of lesser or equal depth from root. Unfortunately, if the developer at the lowest level of nesting performs code generation, they break the build for their teammates.

The workaround for now is to have all developers run a post-processing script on .project to remove the parent prefix:

find . -name .project | xargs sed -i 's|$%7BPARENT-[[:digit:]]\+-PROJECT_LOC%7D/usr/share|/usr/share|g'

To get paths like this:

        <link>
            <name>Drivers/STM32F4xx_HAL_Driver/stm32f4xx_hal.c</name>    
            <type>1</type>    
            <locationURI>/usr/share/stm_repo/STM32Cube_FW_F4_V1.25.1/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c</locationURI>    
        </link>

It would be nicer if there was a way to avoid needing to jump through all these hoops when using the IDE.

This thread is a follow-up to one of the issues mentioned in https://community.st.com/s/question/0D53W00000GixKXSAZ/stm32cubeide-project-setup-for-collaboration-with-version-control