STM32CubeIDE: why when I specify Core/Inc path as include path, IDE shows warning about missing CM4/Debug/Core/Inc?

[HTD]

I try to specify relative paths without a lot of ../../.. spaghetti, but every time I shoot into the correct directory, I get an error like a /Debug/ was added to my path?

I moved all my code files, now I want to make include paths right, but it's either using workspace folder, or... IDK. It accepts absolute paths, but I don't accept absolute paths.

My whole point is to make the simplest possible folder structure for both STM32CubeIDE and other tools.

I don't get it. My project root (a directory where the .project file is located) is ROOT. I'd think when I have to include directory ROOT/DIR all I have to do is to specify "DIR" as include path. Or "./DIR". But nothing works. STM32CubeIDE insists on adding /Debug/ to my paths. I tried adding "../" 1, 2, 3, 4 times. If I add too many "../" then it resolves the directory correctly as incorrect - so the path ending is correct, as specified, just the root is wrong. However, when my "root" is just ".", then it adds "/Debug/" to it and treat is as invalid, because naturally there's nothing there.

OK, I found out that the include path root is "Debug/CM4" - how to change it to "/"?

[Paul1]

In Debug folder is the compiled stuff (.o .o .make etc.).

Your source files (including any mx generated) shouldn't be under Debug

I suggest making a "ProjectCode" folder next to "Core" folder to hold your custom files separate from any MX files (generated or copied). This can also make easier for version control or backup.

If moving/copying project keep the path depth same or any relative paths will break.

Before setting include folders in MX you need to set Source folders, then set include folders within a source folder you specified for the project. (Careful not to include from a different project or can get messy in many ways).

Paul

[HTD]

Of course my files are not under Debug. I just don't know why the STM32CubeIDE thinks it's the project's root, and, what's even weirder, it doesn't think so when it comes to TouchGFX includes. It actually thinks the root folder for them is somewhere else.

What really triggers my OCD are include paths like this:

"../../CM7/../../CM7/TouchGFX/..."

I tried to remove the redundant parts from those paths but well... all hell broke loose. I had to discard those changes quickly. First of all, the "../../CM7/../..CM7..." includes are back pretty soon. Something restores them. The first build shows no errors or warning. The second one shows invalid include directory, but passes. Something is really wrong with this system, but I don't have the time to investigate it.

Anyway, I tried to move my project root from STM32CubeIDE folder to 1 folder below, to not have duplicated folders and so many links instead of just something clean...

I failed miserably. I've lost a day of work, retreated with shame, discarded all changes form git and decided not to touch the directory structure ever again ;)

My files are in the special directory right under root. They naturally would not be compiled as they are below CM7 folder, so I added a workspace link for my directory. It works, everything builds...

One small issue though - my new directory (below CM7) is not visible to TouchGFX simulator build. The TouchGFX build tool has no option to include an extra directory with C files. But well, my directory contains code that is not applicable for the simulator anyway, it's all hardware specific. So I just have my "#ifndef SIMULATOR" parts to forget about any references to my extra directory. It does additional good job of separating the hardware backend from the GUI. The GUI for the simulator should just display some mockup screens to test if the clicking works as intended. The real logic is not for the simulator anyway.

BTW, I have a fair amount of custom GUI code and I keep it in the Model and Common directories of touchgfx/gui. The simulator sees it and it allows me to test my custom widgets without actually downloading everything to the device.

I think there's really no way to entirely separate my code from the generated code here. There are too many files scattered over too many directories. I had to hack BSP drivers, make changes to TouchGFX initialization files... I only succeeded to not touch the main.c / main.h. Those files are governed entirely by device configuration tool.

I discovered one weird quirk of STM32CubeIDE - it will overwrite changes in most of the HAL, except the ROOT/Drivers/BSP. Thank god. There's a bug there when I2C4 is enabled, one of the function gets in a name clash with main.c generated code. I renamed the offending function there and fortunately my changes are not overwritten on code generation.

[Pavel A. · Accepted solution]

Welcome to Eclipse CDT )

Eclipse documentation advises against using relative paths because they can easily get wrong.

Luckily it provides "environment" variables for the project directory and the workspace directory.

With these you can easily make your include paths.

In your example it will be ${ProjDirPath}/DIR

Note that ${ProjDirPath} is absolute, this is how relative paths are avoided.

The current directory for Eclipse builder is not the directory with .project, it is a first level subdirectory named as the configuration (hence Debug and Release, or any other if you've defined).

${ConfigName} is the current configuration.

${ProjName} is the project name from the .project file (visible in Project Explorer).

Finding the repository root is not so easy. Eclipse provides a path variable ${WorkspaceDirPath} for the workspace root, but the workspace is not necessarily at the source tree root.

Then you need to use paths relative to ${ProjDirPath}.

CubeIDE provides additional variables: ${active_core_build_dir}, ${cubeide_cubeprogrammer_path}, ${gnu_arm_embedded_compiler_path} and so on.