PFW-1460 Update build scripts

[3d-gussner]

Builds all firmware.

Tested on

• Linux (Ubuntu 20.04 LTS)
  • git clone
  • download zip
• Windows 10
  • git clone
  • download zip

UPDATE 10 July:
It turns out that cmake on Windows and maybe also on MacOS has issues with wildcard usage, while Linux works fine.
Created #4708 to solve this issue.

[github-actions]

All values in bytes. Δ Delta to base

Target	ΔFlash	ΔSRAM	Used Flash	Used SRAM	Free Flash	Free SRAM
MK3S_MULTILANG	0	0	247784	5653	6168	2539
MK3_MULTILANG	0	0	247082	5662	6870	2530

[3d-gussner]

While testing Windows 10 the build.py script fails during compressing, while the Linux version is working correctly.
Looking into that.

[sarusani]

The problem is not in the build.py. I get the same error when I run the "ALL_MULTILANG" CMake directly from VSCode. (Windows)

All multilang builds for MK25 & MK25S variants fail.
(English only builds work fine, so do all builds for MK3 & MK3S variants)

I'll have a closer look on the weekend.

[3d-gussner]

I think something goes wrong here on windows https://github.com/prusa3d/Prusa-Firmware/blob/MK3/CMakeLists.txt#L594-L595
Can you check on Windows if build\release\release is created which would be https://github.com/prusa3d/Prusa-Firmware/blob/MK3/CMakeLists.txt#L594

Or maybe it takes bit longer on Windows to create the directory and the next line is executed too early?

[sarusani]

Windows doesn't like the ${variant_name}_${FN_VERSION_SUFFIX}_en*.hex.
The wildcard doesn't work. If you (just for testing) change it to ${variant_name}_${FN_VERSION_SUFFIX}_en-ro.hex the build works.

PS:
I think the problem is that in linux the filepath is resolved by the shell and then passed to cmake. In windows this doesn't seem to be the case...
(Not sure about this 😄)

[3d-gussner]

@sarusani Please try #4708 + this PR.