Project gives error even if nothing has changed

[Robert Ritchey]

I have a problem on a new project I have never encountered before.  When I go to rebuild I aways get the following error for the same files or when I try to debug right after building: 

make -j8 all

make: stat: F:/Projects/Smart-Fly/PwrEq/MCUs/STM32/STM32G0xx/Drivers/STM32G0xx_LL_Driver/Inc/stm32g0xx_ll_bus.h F:/Projects/Smart-Fly/PwrEq/MCUs/STM32/STM32G0xx/Drivers/STM32G0xx_LL_Driver/Inc/stm32g0xx_ll_comp.h: Invalid argument

make: *** No rule to make target 'F:/Projects/Smart-Fly/PwrEq/MCUs/STM32/STM32G0xx/Drivers/STM32G0xx_LL_Driver/Inc/stm32g0xx_ll_bus.h F:/Projects/Smart-Fly/PwrEq/MCUs/STM32/STM32G0xx/Drivers/STM32G0xx_LL_Driver/Inc/stm32g0xx_ll_comp.h', needed by 'Sources/Units/QCM/MCUs/STM32G030C6/Firmware/Unit/src/SysCtl.o'. Stop.

"make -j8 all" terminated with exit code 2. Build might be incomplete.

I have not seen this on other projects and cannot figure out what is different in this one. When I clean and then go to debug the projects rebuilds and will go into the debugger. bus.h and comp.h are not even referenced in any of my files. 

Anyone seen this behavior?

[Pavel A. · Accepted solution]

Is this a cube-generated ("managed") project? CubeMX or CubeIDE? Which version? 

Try to change the builder type in the project settings: external to internal or v.v.

C/C++ build -> Builder settings ->  Builder type

[Robert Ritchey]

This was started under CubeIDE.  Changing to internal fixed the problem but I checked my other projects that do not exhibit this strange behavior and they use external.  The problem project had exactly the same builder settings as all my other projects.  Don't understand why changing to internal fixed the problem? 

STM32CubeIDE
Version: 1.14.0
Build: 19471_20231121_1200 (UTC)
OS: Windows 7, v.6.1, x86_64 / win32
Java vendor: Eclipse Adoptium
Java runtime version: 17.0.8.1+1
Java version: 17.0.8.1

[Pavel A.]

Frankly I don't understand myself why it helps. With a real ("external") make this can be caused by some of dependency file's time set in far future. When you switched to the internal builder, all generated makefiles have been purged, maybe some of these was the culprit. If you switch back to external, will the problem re-appear?

[Robert Ritchey]

Changing it back reverts to the same previous behavior.  I have to keep it at internal keep from getting an error after I compile and then try to debug.  Tells me there is no rule to make those 2 header files ( and always just those 2 header files ).  I have no idea what I did different on this project than all my others that work just fine in this scenario.  Thanks

[Pavel A.]

> Tells me there is no rule to make those 2 header files ( and always just those 2 header files ).

These filenames could come implicitly, from applying some pattern rules, or even obscure bug of the make version ported to Windows.

Well then use the internal builder - just note that post-build actions (print sizes, conversion to hex/bin) may fail with internal builder (bug already reported) - but these actions can be easily added back, as a post-build step.

[Robert Ritchey]

I am not sure what those bugs are.  I may just start over on the project, its not that large.  Very frustrating. 

Thanks for your help. 

[Pavel A.]

The GNU library ported to native win32...effect of resolution of timestamps on different Windows filesystems or bugs in conversion between Windows and Unix times... Too obscure for normal people, just find a reliable way around it and leave frustration behind you))