Nightmare on Linked Resource street!

[Robmar]

I added a Linked Resource and tested it on an include line, although the path is the same, it fails.
I have zero idea why, does it need another syntax?

Path variable:-> REPOSITORY_LOC set as C:\Users\Dev\STM32Cube\Repository

With GCC Copiler Include Paths this fails:- ${repository_loc}/STM32Cube_FW_H7_V1.11.1/Drivers/STM32H7xx_HAL_Driver/Inc

but this works:-

C:/Users/Dev/STM32Cube/Repository/STM32Cube_FW_H7_V1.11.1/Drivers/STM32H7xx_HAL_Driver/Inc

I tried with '\' and '/' no difference.

Why would this cause these errors:-

C:/Users/Dev/STM32Cube/Repository/STM32Cube_FW_H7_V1.11.1/Drivers/CMSIS/Device/ST/STM32H7xx/Include/stm32h7xx.h:282:11:
fatal error: stm32h7xx_hal.h: No such file or directory

282 | #include "stm32h7xx_hal.h"

| ^~~~~~~~~~~~~~~~~

[Andrew Neil]

---

@Robmar wrote:

 

C:/Users/Dev/STM32Cube/Repository/STM32Cube_FW_H7_V1.11.1/Drivers/CMSIS/Device/ST/STM32H7xx/Include/stm32h7xx.h:282:11:
fatal error: stm32h7xx_hal.h: No such file or directory

---

So it can't find the file stm32h7xx_hal.h.

Use the Windows File Explorer (or whatever) to find if/where that actually exists on your hard drive

• If it doesn't exist, then no amount of fiddling with the project settings can fix that.
• If it does exist, make sure that location is in your Include Paths.
  Easiest way to do this is to find the folder in the CubeIDE Project Explorer, right-click it, and choose 'Add/remove include path'

[Robmar]

As I wrote, with the linked path name "repository_loc" replaced with the same path text it works.

The problem is that the path name is the exact same path string, so why does it fail when the linked path "repository_loc" is used, as they are the same?

[TDK]

Path variables are an Eclipse convention. Are they properly expanded before being passed to the compiler/linker? Show the full output of the Console tab so we get the full picture of what's going on. I doubt they're case sensitive, but that seems like an easy thing to get consistent.

[Robmar]

It all links perfectly until I add the linked resource path as indicted above and used it in an include.

Using the include path below, it throws up errors for the CMSIS directory**

${repository_loc}/STM32Cube_FW_H7_V1.11.1/Drivers/STM32H7xx_HAL_Driver/Inc

Error:-> **C:/Users/Dev/STM32Cube/Repository/STM32Cube_FW_H7_V1.11.1/Drivers/CMSIS/Device/ST/STM32H7xx/Include/stm32h7xx.h:282:11: fatal error file not found

repository_loc is set to C:\Users\Usuario\STM32Cube\Repository

If I put the include as: C:\Users\Usuario\STM32Cube\RepositorySTM32Cube_FW_H7_V1.11.1/Drivers/STM32H7xx_HAL_Driver/Inc then it all works (using same '/' or '\')

 

[TDK]

If you post the output I asked for, I will try to help. Without that, all I can say is ensure the system is properly expanding the variables and that the files exist at the location.

The GCC compiler and linker are not prone to bad behavior.

 

> repository_loc is set to C:\Users\Usuario\STM32Cube\Repository

> Path variable:-> REPOSITORY_LOC set as C:\Users\Dev\STM32Cube\Repository

So which one is it?

[Robmar]

I just found a similar bug report about link resources on Eclipse which sounds very similar:-

https://stackoverflow.com/questions/42816181/it-seems-not-possible-to-include-in-my-project-a-path-to-a-folder-that-has-bee 

I don't want to have to add every single include file from the Repository to my project to solve this!

I wonder of a solution is possible?

[Pavel A.]

Yep this is nightmare!  Eclipse historically has two kinds of "path macros": one used in linked resources in .project files. This is common for all types of Eclipse projects. Another type are Build variables, these sit in .cproject files and are specific to CDT projects. Their syntax is a bit different, please note well how they are formatted when edited via Eclipse settings. The most confusing and gross is that the former variables do not work in most of CDT (include paths, source paths etc.) Again please edit these in the GUI settings first and note the usage, before tampering in .cproject files manually.  Always use the Unix form of slash (/). Eclipse will substitute before running commands.

But it is possible to make it work. We use these in most of our CubeIDE projects, they are portable between Linux and Windows, and are independent of user names.

[Robmar]

You mean I have to hack the .cproject file and manually change the paths to fix this bug, to what exactly?

I'm trying to make the project portable to other PCs given the dumb use of the user directory on windows to store the ST Repository!

[Pavel A.]

If you only want to replace one username to another, you already named your solution. it does not require changes in the project. For more thorough cure of include and other paths in project, consider using Build variables. These can be defined in GUI, no manual hacking needed. Their use are similar to macros in makefiles.

 

[Robmar]

Sure, great hack, so all our developers are forced to change (or add a matching) username for every STM32CubeIDE project they import! Great! So STM==utter rubbish dev tools!

 

So you're confirming that linked resources just doesn't work, here we are in 2023 just like back in 1983!

No offer from STM to fix this bug, and now you say to use Build variables, without any suggestion of how a build variable could replace a link resource.

I've not seen build variables used in the include dialog box, is that even possible?

[Pavel A.]

> So you're confirming that linked resources just doesn't work,

Linked resources work - if done correctly. This are part of core Eclipse. ST should have made a non-trivial effort to break it )) But Eclipse CDT could have better integration of linked folders and build variables. Maybe I'd try to fix it when I retire. Sure it will wait for me;)

> I've not seen build variables used in the include dialog box, is that even possible?

Just as all these ${variable} names. Just note that build variables belong to project configuration. Must be copied (or customized) in each configuration. Linked folders/files are global for all configurations (simply because they are in  .project  rather than in .cproject file)