false "file not found" errors during compile on STM32

[PerennialNovice]

During compile, it sometimes happens that there is one or more "file not found" error.
But if I rebuild the same project immediately, there are no more errors.

recipe.c.o.pattern
'Finished building: C:\Sloeber\arduinoPlugin\packages\STMicroelectronics\hardware\stm32\2.7.1\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_pcd_ex.c'
process_begin: CreateProcess(NULL, recipe.c.o.pattern, ...) failed.
make (e=2): The system cannot find the file specified.

make[1]: *** [libraries\SrcWrapper\src\HAL\subdir.mk:929: libraries\SrcWrapper\src\HAL\stm32yyxx_hal_qspi.c.o] Error 2
make[1]: *** Waiting for unfinished jobs....
'Starting C compile'
recipe.c.o.pattern
process_begin: CreateProcess(NULL, recipe.c.o.pattern, ...) failed.
make (e=2): The system cannot find the file specified.

make[1]: *** [libraries\SrcWrapper\src\HAL\subdir.mk:936: libraries\SrcWrapper\src\HAL\stm32yyxx_hal_ramcfg.c.o] Error 2
' '
'Finished building: C:\Sloeber\arduinoPlugin\packages\STMicroelectronics\hardware\stm32\2.7.1\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_pka.c'
' '
'Finished building: C:\Sloeber\arduinoPlugin\packages\STMicroelectronics\hardware\stm32\2.7.1\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_pssi.c'
'Finished building: C:\Sloeber\arduinoPlugin\packages\STMicroelectronics\hardware\stm32\2.7.1\libraries\SrcWrapper\src\HAL\stm32yyxx_hal_pwr.c'

I checked, and the .o files are in fact not there.

This is quite a big project with >100 files and I use parallel build.
It happens way more often when doing a clean build.

I already asked on the STM32 github and was redirected here ...

---

Describe your environment
Sloeber product v4.4.3
OS: Win 11

[jantje]

The compile command make shows is "recipe.c.o.pattern" which is not correct.
"recipe.c.o.pattern" is the environment variable that contains the actual command. If the expansion of "recipe.c.o.pattern" returns nothing sloeber will use "recipe.c.o.pattern"

It looks to me as if Sloeber has not yet been able to initialize the project properly and therefore generates "wonky" build commands.
Pre V5 Sloeber the initialization of Sloeber is a bit hit and miss. 2 things require initialization: opening the project and project properties->sloeber->apply (there may be more but these are most likely)
If my assumptions are correct once you have been able to build after these actions the build should keep on working.
Can you (dis)confirm this behavior?

[PerennialNovice]

Sometimes it happens that I get this error two or more times in a row before I get a successful build.
When I had a successful build it usually works for a while.
I have not found out what actions there were prior to the error condition...
I can keep the initialization in mind whenever it happens again

on the other hand, I wanted to test V5 for a while, maybe this is a good opportunity

[jantje]

on the other hand, I wanted to test V5 for a while, maybe this is a good opportunity

There is still no migration from V4 to V5, there will never be a migration from V5 to V4 and V5 is still in gamma. So unless you are capable of creating a setup you that allows you to relatively easily switch between V4 and V5 I would not move my "production" code to V5.
For stm32 a open question is: Does the solution we found for the SrcWrapper library still work in V5.

[PerennialNovice]

yes, read about that somewhere...
just tried creating a new project in V5 and copied my code into the src folder.
is it possible that V5 has problems with subfolders in the src folder?

[jantje]

is it possible that V5 has problems with subfolders in the src folder?

It is possible but unlikely.
There are quite a lot of unit tests that are dependent on source code in subfolders.

[PerennialNovice]

Can you (dis)confirm this behavior?

I now can confirm, that after a successful build, I can do several clean builds without the error occurring. Did this 4 times in a row, always deleting the build folder (and patiently waiting 3:30 minutes because on windows the STM32core is really, really slow. Same code on a comparable Linux machine takes about 20s to compile ...)

I then went to sloeber properties and clicked apply ... compiled without error - twice
I then closed the project and reopened it ... compiled without error - twice

all this without change to the properties or any change to the code

small changes to the code or change to optimization settings in the sloeber project-properties dialog did not trigger the error as well

only other change: I upgraded STM32core from 2.7.1 to 2.8.1, had them both installed for a while and now have removed 2.7.1

so I reinstalled 2.7.1 and have both again - no error

Seems that starting with the moment I decided to systematically try to reproduce it, it just doesn't happen again :(

[jantje]

Seems that starting with the moment I decided to systematically try to reproduce it, it just doesn't happen again :(

I know the feeling. 😃

[PerennialNovice]

Now I can confirm that it does happen without opening the properties dialog.
Just made some code changes and deleted a file (that was excluded from build beforehand)

[jantje]

Yesterday I was working in Sloeber V4 to prepare for migration code development and I had this exact same issue with an Arduino mega. Simply trying to build again and it worked fine.
As I never have seen this before I would assume something must have changed in eclipse/CDT that triggers this behavior but looking at the install details on my system I need to rule this out.
On my system there are 2 more suspects: java (I'm currently running on Java 17) and my system itself (I upgrade from 2 cores to 12 cores) both can cause differences in thread execution sequence which this looks like.
Note that in Sloeber V4 the sloeber project exists as a different entity from the CDT project and both have configurations. Where as in V5 the sloeber project no longer really exists (as it is part of the CDT project) and the Sloeber configuration is part of the CDT configuration.
This simplifies house holding dramatically.

[PerennialNovice]

some similarity then: 12 cores here as well and parallel build for all of them enabled

[jantje]

The problem happens before the parallel build even starts

[PerennialNovice]

I dont think this issue is platform-dependant, but nevertheless I thought I'd share that I have it on ESP32 platform as well

[jantje]

I stated I experienced this with a mega.
So it is not Arduino platform specific.
It may be eclipse platform specific
Platform stands for many things.
I hope this is fixed in V5