improvement: BLAS support on all CI configurations on Github workflows

[luau-project]

What?

I have improved BLAS building/testing on all supported CI configurations on Github workflows (Ubuntu, MSYS2, MSVC).

Why?

It eases the process to check if future changes to the code is somewhat damaging the current state for BLAS support.

How?

• On Ubuntu, I simplified the building/testing with BLAS by installing the library libblas-dev;
• On MSYS2, there are builtin packages named mingw-w64-x86_64-blas, mingw-w64-ucrt-x86_64-blas and mingw-w64-clang-x86_64-blas for every MSYS2 environment (mingw64, ucrt64, clang64), respectively. So, I'm just installing it and building/testing against it;
• On MSVC, the most challenging changes, I had to do a major rework to support BLAS:
  1. First, since BLAS is a Fortran library, and there's not a "simple" manner to install a Fortran compiler which generates MSVC ABI-compatible binaries, I had to install LLVM flang-new https://flang.llvm.org/docs/ Fortran compiler from conda-forge channel using miniconda https://docs.anaconda.com/miniconda/;
  2. Then I download BLAS from its repository https://github.com/Reference-LAPACK/lapack and build the library with LLVM flang-new;
  3. Then I'm uploading the built BLAS library as artifact;
  4. All these steps from (i) to (iii) were done in a separate job, called build-BLAS;
  5. The main cminpack testing job (cminpack-visual-studio) downloads the built BLAS library from the build-BLAS job execution and performs the building / testing of cminpack.

[!NOTE]

In the MSVC CI rework, I had to remove the building/testing of x86 binaries.

[devernay]

My main comment is that if testing has to be done, it shouldn't be against the reference BLAS implementation, which is basically the same as the native minpack code, but against a modern implementation. I think OpenBLAS fits that purpose, as it's 10x faster than the reference implementation. It's also available for any platform, including MSVC (see https://vcpkg.link/ports/openblas).

Then, I don't think we should add a new dimension to the testing matrix for every feature we want to test. Only one configuration has to be tested with BLAS support. This is what I did for Linux, please do the same for Windows. The same would hold if/when we add LAPACK support to the cmake builds (it's easy, the code is there already)

[luau-project]

Update

I have followed your advices:

• building BLAS only for a single matrix config;
• using OpenBLAS implementation for BLAS on all supported CI configurations (Ubuntu, MSYS2, MSVC).

[!NOTE]

Since you voted for a compact build matrix, I took the choice to narrow the matrix for the most common build types on every workflow (Release, Debug).

[luau-project]

On a test branch (not committed here), I was able to also build / test cminpack (+ OpenBLAS) with clang-cl, which is clang with ABI-compatibility to MSVC toolchain. IMO, it is a nice addition to the MSVC CI.

Would you like to add it?