MSVC/Flang support (Windows)

[richardotis]

Checklist

• Used a fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

This PR switches the Windows build over to the newer compiler infrastructure using MSVC and Flang, retiring the MinGW build. According to a reverse dependency analysis, the only feedstock which will be affected is ipopt (and I have ongoing work to address that in conda-forge/ipopt-feedstock#34).

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[richardotis]

It looks like the way OpenBLAS handles this is forcing the use of clang: https://github.com/conda-forge/openblas-feedstock/blob/631acd1244709ed8872494b1d40d0195b4049e4f/recipe/bld.bat

Specifically, OpenBLAS forces clang-cl, which is "an alternative command-line interface to Clang, designed for compatibility with the Visual C++ compiler, cl.exe." (Details on https://clang.llvm.org/docs/UsersManual.html#clang-cl ). Overall, Clang strives for ABI compatibility with MSVC: https://clang.llvm.org/docs/MSVCCompatibility.html

The inability to use the MSVC compiler is possibly related to flang-compiler/flang-driver#75
The odd thing is I can still let it use the MS link.exe, and everything works. I'll note that I have to use WINDOWS_EXPORT_ALL_SYMBOLS to get the Fortran examples to link, and this appears to crash MSVC, but not clang-cl. If that issue were resolved, perhaps the pure MS toolchain would work here.

I'll test this, but I think it's fine to use Clang here to build shared libraries while downstream uses MSVC. Local testing appears promising.

[richardotis]

This is ready for review.

[isuruf]

I'll note that I have to use WINDOWS_EXPORT_ALL_SYMBOLS to get the Fortran examples to link, and this appears to crash MSVC, but not clang-cl.

It's not MSVC that crashes, it's CMake that crashes. See https://github.com/conda-forge/pymdi-feedstock/blob/c620ef2d8069301a194aef0fe41658ac4568fcd8/recipe/bld.bat#L8-L11

[richardotis]

Any comments from the feedstock maintainers?

[richardotis]

I'd be interested in those using downstream packages to try this packaging of mumps. I packaged this on the pycalphad anaconda.org channel, and while it mostly works, there seems to be a few downstream test failures. The mumps tests themselves seem to pass without a problem, so I'm not sure if it's a downstream issue. (This was never an issue with the MinGW-based builds.)

For me the dependency chain looks like
mumps (tests pass) -> ipopt (6/44 tests fail) -> pycalphad (6/123 tests fail)

I'm still investigating, but I wanted to give a heads up to other maintainers in case they want to test against their own packages.

[minrk]

I don't have any relevant knowledge of windows builds, so I'd just have to trust you, but it looks AOK to me. I'd like to let @jbweston weight in, but I'm also okay merging this if we don't get any negative feedback soon.

[moorepants]

Shall this be merged?

[richardotis]

By the way, I investigated the downstream test failures and confirmed the exact same ipopt test failures when using the (current) MinGW-based conda-forge mumps.

I still don't know what's causing the downstream failures, but I believe this is safe to merge.

[moorepants]

@conda-forge/mumps Can an owner of this repo approve and merge this PR? Seems like there aren't any objections.

[basnijholt]

I know too little about Windows builds to make a good judgement.

However, if no one has objections I will merge tomorrow ;)

[moorepants]

Thanks!

[moorepants]

It looks like the build on master failed.

[richardotis]

@conda-forge-admin please rerender