[mumps] Add new port

[tmmsartor]

Add new port for Mumps-Solver with Coin-Or autotool build.
This is intended to work with existing port coin-or-ipopt.

• Changes comply with the maintainer guide.

• SHA512s are updated for each updated download.

• The "supports" clause reflects platforms that may be fixed by this new version.

• Any fixed CI baseline entries are removed from that file.

• Any patches that are no longer applied are deleted from the port's directory.

• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.

• Only one version is added to each modified port's versions file.

• Changes comply with the maintainer guide.

• The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.

• Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx.

• The versioning scheme in vcpkg.json matches what upstream says.

• The license declaration in vcpkg.json matches what upstream says.

• The installed as the "copyright" file matches what upstream says.

• The source code of the component installed comes from an authoritative source.

• The generated "usage text" is accurate. See adding-usage for context.

• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.

• Only one version is in the new port's versions file.

• Only one version is added to each modified port's versions file.

[dg0yt]

Maybe start small?

[dg0yt]

If you need blas and lapack, use the ports blas and lapack.

[tmmsartor]

I tried that first, but it seem the lapack underlying package on Linux lapack-reference does not provide the C interface with the name mangling expected by coin-or built libraries.

To add more context, at the moment coin-or-ipopt (which use a autotool based build configuration similar to the one of this package) is using intel-mkl which is another blas+lapack implementation, but quite heavier in term of size,
I wanted to try if also openblas could work. Ideally providing intel-mkl as optional feature given it can be more performant. Also other projects using this "stack" ipopt+mumps (like casadi #43425) are using openblas for lapack implementation.

The problem I had with vcpkg lapack metapackage was the same of this coin-or-ipopt issue (#33860) . This may be also related to why coin-or-ipot port built is failing on CI for linux recently, I may be wrong, I didn't double check.
Switching to openblas was the easier thing for me to have a working build, but I can iterate to avoid modifying existing packages.

[dg0yt]

For linux, lapack selects lapack-reference, while blas selects openblas.
This might not be optimal. But it shouldn't be tuned per port.

Also other projects using this "stack" ipopt+mumps (like casadi #43425) are using openblas for lapack implementation.

I don't see any blas or lapack dependencies in https://github.com/Microsoft/vcpkg/blob/master/ports/casadi/vcpkg.json

The problem I had with vcpkg lapack metapackage was the same of this coin-or-ipopt issue (#33860) .

The solution reported in #33860 is "carry the transitive usage requirements". Ideally this should be handled via pkgconfig and cmake from the port which has these requirements.

[tmmsartor]

@microsoft-github-policy-service agree

[dg0yt]

I found that MUMPS points at https://github.com/scivision/mumps for a CMake build system. That repo seems maintained, and it might be a much better fit for a vcpkg port than an autotools build.

[tmmsartor]

I found that MUMPS points at https://github.com/scivision/mumps for a CMake build system. That repo seems maintained, and it might be a much better fit for a vcpkg port than an autotools build.

Thanks for the suggestion, I was aware of it but haven't tried it yet. I would also prefer to use CMake, I will give it a try.