Remove MSVC limitation

[AlessioZanga]

Hi there! I've tweaked the CMakeFiles.txt to allow LAPACK to be compiled in MSVC using vcpkg. Essentially I've patched vcpkg to provide the gfortran compiler as default Fortran compiler.

The build steps are:

• Install vcpkg,
• Execute vcpkg install openblas.

A reproducible pipeline example can be found here.

If this pull request will be accepted, I'll update my vcpkg fork to this ref and submit a pull request to integrate this changes.

[martin-frbg]

Thank you. The assumption so far was simply that one would either use msvc or install both gcc and gfortran. (Probably need to check that NOFORTRAN gets set automatically for msvc without gfortran)

[AlessioZanga]

Actually, the NOFORTRAN flag was set to NO using vspkg, but even removing that LAPACK was disabled by the BUILD_WITHOUT_LAPACK, which is automatically set for MSVC.

I'm unsure if BUILD_WITHOUT_LAPACK should be removed of just set to OFF by default. What do you think?

[martin-frbg]

I think the BUILD_WITHOUT_LAPACK option itself needs to stay

[AlessioZanga]

It seems that the pipeline (Windows_flang_cmake) hit the time limit. It compiled successfully, but was stopped around the 29th test over 115, also some tests failed.

[martin-frbg]

Yes, that failure is strange as clang/flang builds should be unaffected by your PR. (Also the failed tests are BLAS i.e. C code with only the test drivers in Fortran) Maybe the conda llvm got upgraded yesterday

[AlessioZanga]

Many thanks for the clarification! Indeed, I noticed they were C-related, but I wasn't sure whether there was any side effect of the PR

[AlessioZanga]

Are there any news? May I help you in any way?

[martin-frbg]

Sorry for the delay - I have been trying to figure out how your PR managed to break the Windows clang/flang CI job, although the changes it brings looked to be unrelated.
Now I realize that it actually un-breaks that job (seems there is an MSVC environment although the build does not use it, so previously the flang compiler never executed).
What it does appear to expose is a failure of the flang compiler, which appears to have miscompiled a few Fortran-based BLAS tests. These involve reading the name of the output file to create from the respective input file. And when the ctest tool tries to scan the output for errors it does not find the file as it has been created with extra characters - some junk characters prepended and the original string quotes still present. (SBLAT2.SUMM became 'SBLAT2.SUMM' etc.)
EDIT: I knew they looked familiar, this is just the UTF8 BOM (byte order mark) prepended, so the actual problem may be in whatever Windows version of git (or its local settings) used to download the sources and inputs to the CI instance.

[AlessioZanga]

No problem for the delay, I was just curious about how the changes involving the flag affected the compilation. Also, thank you for your time, indeed it was a really unexpected side-effect!

[AlessioZanga]

Thank you for merging the pull request! I'll now update my vcpkg fork and open a draft pull request on their repository, waiting for the next release of OpenBLAS.

[Neumann-A]

break the Windows clang/flang CI job,

Where is the script which setups/builds flang on windows? Maybe I can steal it and add it to vcpkg ;) I assume that this is flang-classic?

[martin-frbg]

We just grab the package from conda, guess you'd need to dig around in https://github.com/conda-forge/flang-feedstock/tree/main/recipe or contact @isuruf
BTW I still haven't figured out why the cursed powershell on Azure CI prepends a BOM to the contents of the test files, so I just skip the tests when this occurs.