STM32CubeIDE project setup for collaboration with version control

>  This works if we make a symlink to the STM32Cube/Repository/ in the same relative location for all of us. But then we get absolute paths in .cproject.  Is there a way to have the IDE to use something like ${Firmware_Repo} for these paths?

Sure, yes. You can symlink the Cube repository to common absolute path, for example under /usr/src or /usr/share.

Then define an Eclipse "build variable" Firmware_Repo to that absolute path.

You can also make paths of Cube HAL drivers and other C files under the cube repository relative to such variables. This is more cumbersome.

Need to define a Path variable in the project's Linked resources, and add these files using these path variables.

In this way we share Eclipse projects among several developers working in Linux and Windows.

-- pa

Thanks for the advice Pavel.

To clarify the steps:

1. Create a symlink to the stm repo:

sudo ln -s ~/STM32Cube/Repository /usr/share/stm_repo

2. Add this as a path variable in "Window > Preferences > General > Workspace > Linked Resources"

3. Use this path variable for the firmware repo in "Window > Preferences > STM32Cube > Firmware Updater".

Unfortunately, I can't figure out how to just use the "stm_repo" variable, and must instead use "/user/share/stm_repo".

4. Create a new project. It will point to the same path set in the firmware updater.

Unfortunately, there are still lots of paths hardcoded for my machine in this project:

// .cproject
 
// I assume this is fixed with some manual ${stm_repo} replacements
<option id="com.st.stm32cube.ide.mcu.gnu.managedb
uild.option.defaults.2130474423" superClass="com.st.stm32cube.ide.mcu.gnu.managedbuild.option.defaults" ... /home/miles/STM32Cube/Repository/ST
M32Cube_FW_F4_V1.25.0/Drivers/STM32F4xx_HAL_Driver/Inc ...
 
// Same with:
<listOptionValue builtIn="false" 
value="/home/miles/STM32Cube/Repository/STM32Cube_FW_F4_V1.25.0/Drivers/STM32F4xx_HAL_Driver/Inc"/>
 
// .project
 
// This uses relative paths (e.g. ../../../../STM32Cube) and is not portable across machines
<locationURI>$%7BPARENT-4-PROJECT_LOC%7D/STM32Cube/Repository/STM32Cube_FW_F4_V1.
25.0/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal.c</locationURI>
 
// .mxproject
 
// Not sure what to do about these. Should .mxproject be tracked by git?
SourceFiles=Core/Src/main.c; ... /home/miles/STM32Cube
/Repository/STM32Cube_FW_F4_V1.25.0/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_tim.c; ...
HeaderPath=/home/miles/STM32Cube/Repository/STM32Cube_FW_F4_V1.25.0/Drivers/STM32F4xx_HAL_Driver/Inc ...

So I'm not sure if I'm following your instructions correctly.

Also, it would be ideal if we could jump between firmware versions, and it seems like the only way to do that is with CubeMX. Is it possible to incorporate CubeMX into the workflow you're suggesting?

Yes, you've shown definition of path variables at workspace level.

I prefer to define them at project level because then they go into the .project file and to version control.

<variableList>
		<variable>
			<name>STM32Cube_FW_H7</name>
			<value>file:/usr/src/STM32Cube/Repository/STM32Cube_FW_H7</value>
		</variable>
		<variable>
			<name>STM32H7xx_HAL_Driver</name>
			<value>${STM32Cube_FW_H7}/Drivers/STM32H7xx_HAL_Driver</value>
		</variable>
 ............. etc......

Then you can use these path variables in .project to pull in library .c files:

Note that in locationURI element the variable names occur without ${...}. It's so "intuitive" in Eclipse... ((

Also note that sometimes Eclipse replaces curly braces to hex codes : $%7B .... %7D

<linkedResources>
		<link>
			<name>Drivers/STM32H7xx_HAL_Driver/stm32h7xx_hal.c</name>
			<type>1</type>
			<locationURI>STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c</locationURI>
		</link>
........... etc.......

It takes some time to get used to this.

WARNING: Cube MX and its CubeIDE variant have no idea about Eclipse's linked resources. Regenerating code will break them.

 > Should .mxproject be tracked by git?

AFAIK, no

> Also, it would be ideal if we could jump between firmware versions

For this you can just swap the symbolic links under the common absolute root.

In my example above, STM32Cube_FW_H7 is a link to concrete version, such as STM32Cube_FW_H7_V1.5.0 . It can be redirected to, say, STM32Cube_FW_H7_V1.8.0.

--pa

Thanks for all the help.

Wanted to clarify one more thing:

> define a Path variable in the project's Linked resources, and add these files using these path variables. In this way we share Eclipse projects among several developers working in Linux and Windows.

> I prefer to define them at project level because then they go into the .project file and to version control.

<value>file:/usr/src/STM32Cube/Repository/STM32Cube_FW_H7</value>

Wouldn't that only work among Linux users? That's why I was thinking it would be better to define the link at the workspace level (outside of version control) so it won't break things for the Windows users.