Support clangarm64 environment

[ntkme]

This PR is the prerequisite for: ruby/setup-ruby#750

The complication here is that windows-11-arm runner does not have msys2 preinstalled, so that we have to create a full msys2 package, instead of the current partial update package.

Following the naming convention of ruby-builder, the partial package is named msys2-windows-latest, and the full package is named msys2-windows-11-arm64.

Another tricky problem is the chicken and egg problem that this PR depends on updated setup-ruby in order to run ruby script on windows-11-arm, while the setup-ruby also depends on the artifacts here. So currently this PR is pointing to my fork of setup-ruby, which download msys2 from my fork of setup-msys2-gcc. We can update this later once this is merged and a working build is available in this repo.

[MSP-Greg]

@eregon

Actually, looking at it right now...

[ntkme]

GitHub now blocks user from adding new secret starting with GITHUB in name, which is a pain for me to test in my fork. Switch to custom permission + github.token allows me to run this on my fork more easily without adding a secret GITHUB_TOKEN. Also note that even if the write permission is requested, it will not be granted to PRs (similar to how secret works), so there isn't a security concern.

[MSP-Greg]

@ntkme

Thanks for your work on this. Currently I only have x64 locally, so this is very helpful.

One thing is the renaming of some of the 7z files. I think the MSYS2 files are:

msys2-windows-11-arm64.7z
msys2-windows-arm64.7z
msys2-windows-latest.7z

Maybe we could keep msys2.7z as the x64 name, and use msys2-arm64.7z for arm64?

JFYI, I'm looking at pulling PR's from both repos and generating the arm64 files here...

[ntkme]

Maybe we could keep msys2.7z as the x64 name, and use msys2-arm64.7z for arm64?

That's definitely an option. Honestly I don't have a personal preference here, I was trying to keep the naming conversion aligned with packages in ruby-builder.

[MSP-Greg]

I have no idea if the 7z files created here are used anywhere else (besides setup-ruby). Also, most people would hopefully know that mingw & msys2 are windows specific build tools.

I've got a question that you may know the answer to. On x64, we've got both msys2/mingw based builds (mingw or ucrt) and an mswin (MSVC) build. Given that vcpkg is installed on the arm64 runner, can an arm64 Ruby be built using MSVC?

[ntkme]

Given that vcpkg is installed on the arm64 runner, can an arm64 Ruby be built using MSVC?

The answer in theory is yes, but I don’t think anyone has attempted. There might be issues with build scripts that need to be fixed.

[ntkme]

Updated the PR with msys2.7z and msys2-arm64.7z package names as suggested.

[eregon]

Given that vcpkg is installed on the arm64 runner, can an arm64 Ruby be built using MSVC?

FWIW I saw https://bugs.ruby-lang.org/issues/21277 today on this topic

[MSP-Greg]

@eregon

Thanks.

Certainly won't happen today, but I hope to get head builds in ruby-loco for arm64 mswin & ucrt...

[MSP-Greg]

@ntkme

Again, thanks for your work on this.

Now that the 7z files exist and setup-ruby works, I'm wondering about one issue.

Currently, the 7z files are only replaced if there has been an update. IOW, we'd prefer to not update the files in the release if nothing has changed. I need to review the code more, things like the below. Should windows-toolchain: none be removed?

- { os: windows-11-arm, ruby: 3.4, name: msys2-arm64, type: clangarm64, windows-toolchain: none }

I'm not sure, and I may not have a lot of time for OSS this weekend...

[ntkme]

@MSP-Greg Added a new commit Remove code used for bootstrap msys2-arm64. It should achieve what you're asking for.

[ntkme]

@MSP-Greg Looks like the downgrade gcc step is failing on clangarm64, working on a fix right now.

[MSP-Greg]

Sorry, I didn't think that would be an issue. Do I need to add the packages to the release?

[ntkme]

"gcc" on clangarm64 is just a wrapper script that make clang to accept gcc style parameters... So you cannot "downgrade gcc" on clangarm64 to begin with. - This step should simply be skipped on clangarm64 - Or, if we want to lock the clang version, we need to upload a backup of specific version of gcc-compact and related clang packages:

https://packages.msys2.org/packages/mingw-w64-clang-aarch64-gcc
https://packages.msys2.org/packages/mingw-w64-clang-aarch64-gcc-compat
https://packages.msys2.org/packages/mingw-w64-clang-aarch64-clang
https://packages.msys2.org/packages/mingw-w64-clang-aarch64-clang-libs
https://packages.msys2.org/packages/mingw-w64-clang-aarch64-compiler-rt
https://packages.msys2.org/packages/mingw-w64-clang-aarch64-lld
https://packages.msys2.org/packages/mingw-w64-clang-aarch64-llvm

[MSP-Greg]

So we should skip the downgrade?

JFYI, this is the first time we've had a gcc issue, and this code has been in existence since GitHub Actions was in beta.

[ntkme]

So we should skip the downgrade?

Depends on whether we prefer to lock down compiler version or to receive upgrade when available. If we prefer upgrade, then just skip the downgrade, and we can always add a locked version later if upgrade run into problem.

[MSP-Greg]

Got a fix running in my fork...

[ntkme]

@MSP-Greg I have #23 ready for view - this skip the downgrade of clang right now, but make it super easy to add clang downgrade if we ever need it later.