Cube not finding FreeRTOS and header files when I copy a project to a new directory or use svn

DiBosco · ‎2024-10-15

I have a cube project, that uses FreeRTOS that was in a directory and working fine. Needed putting on svn, which I've done, but when I check it out to a new machine it won't compile telling me that it can't fine FreeRTOS.h, stm32h563xx.h and various others files.

When I look in the original project it looks like it's pointing to a load of hardcoded places to find various files such as:

/home/username/STM32Cube/Repository//Packs/STMicroelectronics/X-CUBE-FREERTOS/1.2.0/Middlewares/Third_Party/FreeRTOS/Source/include/

This is obviously terrible in its own right, but I think it would be better, if possible, that all these requisite source files are copied into the project so there's no worries at all about finding files.

If that's not possible, surely, thse shold be pointing at something like:

$(INST_DIR)/STM32Cube/Repository//Packs/STMicroelectronics/X-CUBE-FREERTOS/1.2.0/Middlewares/Third_Party/FreeRTOS/Source/include/

Or whatever Cube might use for its syntax.

All the FreeRTOS files are not in the project at all, but in some installation directory somewhere.

Even if I simply copy the whole working directory from one place to another on the same machine it won't compile, giving similar sort of errors which just seems bizarre.

Anyone know what's going on here please and how I can set all this up to be able to transferable from one machine to another [via svn or other version control]?

Thanks

Pavel A. · ‎2024-10-15

> it's pointing to a load of hardcoded places to find various files such as: /home/username/STM32Cube/Repository/

Correct, by default CubeMX/IDE install their library stuff under the user directory. This renders the generated projects hostile to version control and multiple developers.

To our customers we recommend to create same directory structure for every developer and immediately after installing CubeMX/IDE set the "repository" path to this global path, for example /usr/src/STM32Cube/Repository/

(this is known as convention over configuration).

DiBosco · ‎2024-10-16

Hi Pavel,

Thanks for the reply.

The problem with this is that although this might work for Linux users, as soon as some poor sap who has to use Windows tries to build the project, it's never going to work. Imposing exact install paths is just terrible, people work in different ways, some people if they're in the Windows world might even have to install on d: rather than c:, in the Unix world some people might not have space in the root directory, or use /opt because that's not affected after an OS update.

Any professional IDE takes where the IDE has been installed as one variable and one where libraries have been installed as another, thus having the $(lib) and $(inst) type variables where everything is relative to these paths and you're not forcing people in a draconian fashion to work in a specific way.

On top of this, it doesn't explain why copying absolutely everything in the directory to a different directory on the same machine doesn't work either. It struggles in exactly the same way to find the FreeRTOS fiels and the headers which I really can't understand.

It sounds like the only way for me to sort this is to copy the FreeRTOS files and the header files into the directory structure that is sent to svn. Is that right? If so, that's a shocking indictment of Cube IDE.

Pavel A. · ‎2024-10-16

Hi @DiBosco

My proposal above works for us even when some people use Windows and some - Linux (we don't have MACs but suspect it will work too). In all paths, Eclipse macros and Build variables use Unix style (/ not \ ) and Eclipse on Windows will fix paths automatically. Of course do not use drive letters. If code spans multiple Windows drives (ex. C: and D:) there's another trick to set up once and forget.

> copy the FreeRTOS files and the header files into the directory structure that is sent to svn. Is that right?

Keeping ST and 3rd party libraries such as FreeRTOS in version control as separate components or sub-modules is a good idea.

> If so, that's a shocking indictment of Cube IDE

Cube IDE is just a sort of Eclipse CDT with a decent debugger and a GNU toolchain. Plus handy host tools on Windows (GNU make and busybox). Nothing less. Anyway, users can demand their money back and get IAR ;)

TL;DR find a decent software consultant who will settle all these tooling chores so your developers can focus on the project.

DiBosco · ‎2024-10-21

Cube IDE is just a sort of Eclipse CDT with a decent debugger and a GNU toolchain. Plus handy host tools on Windows (GNU make and busybox). Nothing less. Anyway, users can demand their money back and get IAR ;)

I would much rather use Rowley Crossworks, it's cross platform, way cheaper and way better support than IAR. It's not that simple though because as processors get more and more complicated, you more and more want and need to use things like FreeRTOS, USB and TCP/IP stacks and ST are really tying you in to using Cube IDE.

In the end, the solution it seems, is to ensure that you only have one project within the workspace and commit the workspace and project together. So you have a workspace per project.

I never really understood or liked the whole workspace thing, never seemed to make sense, so I think to pretend a workspace is a project looks like, long term is going to be the best way to deal with it if you're forced into using a wretched Eclipse based IDE.