CI: add Windows on ARM64

[kmilos]

See https://www.msys2.org/news/#2025-04-18-hosted-windows-arm64-runners-on-github-actions

[kmilos]

MSYS2 is not pre-installed on the image so the setup step takes longer; I guess capacity is still limited/throttled so build time is not the fastest either...

[victoryforce]

build time is not the fastest either...

Let me rephrase this as “build time and developer wait time doubles”. So this CI job severely degrades the CI quality that is the most valuable for a developer, the speed of getting the result: whether or not there are failures when building new code. I have to wait an additional, say, 12-13 minutes to see the “green” or “red” feedback. This has a negative impact on development productivity.

I don’t see any possible advantage that would outweigh this disadvantage.

There is nothing in the darktable codebase that wouldn’t work on a processor with a different instruction set, so constantly checking this for every new code addition doesn’t make much sense.

Instead, we could build nightly, where the extremely slow new build doesn’t matter.

[kmilos]

I tend to agree. There is no rush to merge this (was mainly curious how easy was it to use), we could also wait until the available runners are beefier.

I don’t see any possible advantage

This was one possibility to also cover a more recent Clang MSYS2 typically ships that was put on the back burner...

Instead, we could build nightly

Sure, just makes for a bit more contorted workflow file as NSIS is not available natively, so its installation and packaging steps should be skipped. I can work on this (as a separate PR or replacing this one) if everyone agrees?

[victoryforce]

I tend to agree. There is no rush to merge this (was mainly curious how easy was it to use), we could also wait until the available runners are beefier.

Ironically, now we have switched roles, once you convinced me not to burn watts with the words "The MSYS2 job is just too heavy and slow...". In the end, I agreed with you and sometimes I just run such a build locally. But then another job would only burn watts, but would not delay the completion of the CI run. A huge delay is definitely unacceptable.

I don’t see any possible advantage

This was one possibility to also cover a more recent Clang MSYS2 typically ships that was put on the back burner...

Nothing prevents me from building locally with the latest available Clang in MSYS to occasionally catch and fix build failures (as you can see in #18628).

Sure, just makes for a bit more contorted workflow file as NSIS is not available natively, so its installation and packaging steps should be skipped. I can work on this (as a separate PR or replacing this one) if everyone agrees?

If it's just to check if the build was successful, then it's just extra work that's not really needed. aarch64 is just an architecture with a different instruction set. The success of the compilation depends on the source code and the compiler, not on which target instruction set the code is compiled to.