Issue to build with 'Aggressively cache compiled core' enabled on Windows

[fpistm]

Using the Arduino_Core_STM32, depending of the board and menu option after one build it is not possible to build again when Aggressively cache compiled core is enabled in the Arduino IDE references.

Example

1. First build is ok:
   Archiving built core (caching) in: C:\Users\guest\AppData\Local\Temp\arduino_cache_703236\core\core_stm_stm32_Disco_board_part_num_DISCO_L475VG_IOT,upload_method_MassStorageMethod,Other_serial_enable_Serial,USB_interface_enable_USB,opt_oslto_4e2f2f4828dcde7e63516bf59d4ffb2d.a
2. Second one failed:
   arm-none-eabi-gcc: error: C:\Users\guest\AppData\Local\Temp\arduino_build_927530/..\arduino_cache_703236\core\core_stm_stm32_Disco_board_part_num_DISCO_L475VG_IOT,upload_method_MassStorageMethod,Other_serial_enable_Serial,USB_interface_enable_USB,opt_oslto_4e2f2f4828dcde7e63516bf59d4ffb2d.a: No such file or directory
   But the file exists.

In the second build, the path is higher to 260 (MAX_PATH of windows) due to the arduino_build_927530/.. that's why there is an error. Even if this limitation is disabled it seems Arduino is not able to deal with.
Issue met with Win7 and Win10.
I've shorten option in board.txt and it is now ok. one other solution is to disable the Aggressively cache compiled core in the Arduino IDE references.

I raised this issue here to reference it in the Arduino github. I though some other user could met this. So, I think it should be fine to review arduino cache naming to avoid further issue.

[facchinm]

Hi @fpistm ,
since go 1.9, long paths should be automatically sanitized (see golang/go@2925427).
I'm preparing a Windows build of the builder to check if this problem disappears.
Thanks for reporting!

[fpistm]

Hi @facchinm,
Welcome.
Thanks for the answer.

[facchinm]

After a bit of research, it looks like the problem is not easily solvable, since you use {build.path}/{archive_file} here . Replacing it with archive_file_path should remove the arduino_build_927530/.. part and make the path a bit shorter.

If the path gets too long, using os.Readlink could mitigate the issue; I'll work on a proper fix to also try solving #6751

[fpistm]

Thanks for the tips @facchinm.

[facchinm]

Closing the issue as "solved" (almost 😄 ), keeping track of the Windows-related length issues on #6751.
Thanks!