Use the windows-specific tools/build_openblas.sh on win-arm64

[mattip]

win-arm64 uses a batch file and a different github workflow to build. It would be easier to maintain and move to cibuildwheel if instead it re-used the win-x86_64 workflow which is much more similar to the posix one.

[mattip]

It turns out it is very complicated to get the proper compiler chains to work in a bash script on all platforms

• the llvm chain that is used on win-arm64 does not package flang on windows
• In order to build quickly, the arm64 build uses CMake and ninja. ninja is not available for the make/Makefile builds.
• building OpenBLAS with cmake requires a working mt.exe that apparently can only be provided by VisualStudio, and getting it onto the path is trickier with bash
• conda-forge does provide all the compilers we need, but getting it to work under bash seems also quite tricky.

I tried to get the bash shell path to work on a branch, but I think a better approach would be to stick with the arm64 batch file, and unify the x86 workflow with the arm64 one.

[martin-frbg]

OpenBLAS itself does not require mt.exe (as far as I'm aware), it is just the built-in tests for a valid C compiler in cmake that try to compile something that includes/requires manifest file generation. Not sure if there's a way around this test, but microsoft/vscode-cmake-tools#3502 (comment) suggests that LLVM ships a replacement

[mattip]

I do see an llvm-mt.exe in my installation of LLVM, and indeed the clang-cl.exe check succeeds. The problem is when using the flang-new.exe fortran compiler from conda-forge (similarly for gfortran from rtools) some logic that is specific to LLVM to define _CMAKE_MT_NAMES to llvm-mt.exe is not being triggered. From that issue, I could theoretically set cmake.useVsDeveloperEnvironment to 'never' but how does one do that?

[martin-frbg]

As far as I can tell, this requires a CMakePresets.json file, see microsoft/vscode-cmake-tools#4547 (hopefully the bug regarding Ninja path and other environment variables does not apply when setting to "never"). Alternatively, I would have thought that supplying -DCMAKE_MT=llvm-mt.exe should suffice, but I did not try ?

[mattip]

but I think a better approach would be to stick with the arm64 batch file, and unify the x86 workflow with the arm64 one

I still would prefer bash over a windows batch file, the command line tooling is much more pleasant.

this requires a CMakePresets.json file

I will try this idea. CMake is very particular about what it accepts for -DCMAKE_MT, and I couldn't get it to work, nor could I figure out a way to copy llvm-mt.exe to mt.exe in a way that satisfied CMake.

[mattip]

the llvm chain that is used on win-arm64 does not packages flang on windows

This has been fixed. So we could use the llvm chain from win-arm64 on win-x86_64