Windows ARM64

[jdpurcell]

Adds job for Widows ARM64 w/ Qt 6.5.3. Had to update the runners to Windows 2022 as well due to one of the packages requiring Visual Studio 2022 to compile to ARM64.

[jdpurcell]

This feels dirty but I couldn't figure out a better way. I tried dumping all the environment variables on the runner via Write-Host but I didn't see any that point to the host Qt's folder. Maybe install-qt-action should be enhanced to set this?

[jurplel]

That's a good suggestion for install-qt-action, but this works.

[jdpurcell]

There was a build failure on KImageFormats Win32 which should hopefully go away upon retry. I've had similar failures recently in my pipeline; the aom library is very finicky building for 32-bit and it takes forever.

[jurplel]

Re-running. Please remind me to take a look again tomorrow if I forget

[jdpurcell]

Looks like it built fine that time! I should mention, building aom on 32-bit Windows has been a problem for a while, in fact it failed to compile altogether up until recently due to too much memory usage or stack overflow, so kimg_avif.dll, avif.dll, and aom.dll were missing from the qView 6.x Win32 release due to that. After #3 bumped the vcpkgGitCommitId, it started building fine and reasonably quickly since it brought in this workaround. The workaround was only for Visual Studio 2017 and 2019 though, so moving to 2022 has made it slower and finicky, but it ends up compiling fine maybe 2 out of every 3 tries from what I've seen. Personally I'm fine with that and would rather stay on 2022 to future-proof things (I imagine the Windows 2019 runners will be retired after Windows Server 2025 is released and there are runners for it), but if you prefer to keep the Windows 32-bit build or both non-ARM builds on Windows 2019 for now let me know and I can modify the pull request.

EDIT: Turns out they later changed the workaround to apply for Visual Studio 2022 as well, but by checking for _MSC_VER < 1940. This was true up until Visual Studio 2022 version 17.9 (_MSC_VER=1939), but no longer as of Visual Studio 2022 version 17.10 (_MSC_VER=1940). I reported the bug to AOM's issue tracker.

[jurplel]

Looks like it built fine that time! I should mention, building aom on 32-bit Windows has been a problem for a while, in fact it failed to compile altogether up until recently due to too much memory usage or stack overflow, so kimg_avif.dll, avif.dll, and aom.dll were missing from the qView 6.x Win32 release due to that. After #3 bumped the vcpkgGitCommitId, it started building fine and reasonably quickly since it brought in this workaround. The workaround was only for Visual Studio 2017 and 2019 though, so moving to 2022 has made it slower and finicky, but it ends up compiling fine maybe 2 out of every 3 tries from what I've seen. Personally I'm fine with that and would rather stay on 2022 to future-proof things (I imagine the Windows 2019 runners will be retired after Windows Server 2025 is released and there are runners for it), but if you prefer to keep the Windows 32-bit build or both non-ARM builds on Windows 2019 for now let me know and I can modify the pull request.

EDIT: Turns out they later changed the workaround to apply for Visual Studio 2022 as well, but by checking for _MSC_VER < 1940. This was true up until Visual Studio 2022 version 17.9 (_MSC_VER=1939), but no longer as of Visual Studio 2022 version 17.10 (_MSC_VER=1940). I reported the bug to AOM's issue

Right, that all makes sense. Nice work as always