vcpkg [blas/lapack] force vendor

short summary:

force the lapack/blas vendor within the wrapper
install wrapper stuff from real ports into share/${PORT}
move the correct vcpkg-cmake-wrapper.cmake with the blas/lapack metaport
move FindLAPACK.cmake with the lapack metaport
move the test of lapack/blas in scripts/test_port
Install pc files for blas/lapack with the metaport if necessary.
use version-string in the metaport.

Apr 22 '22 06:04 Neumann-A

Uff, doesn't this create an install order dependency?

    if(NOT EXISTS "${CURRENT_INSTALLED_DIR}/share/lapack/vcpkg-cmake-wrapper.cmake")
        configure_file("${CMAKE_CURRENT_LIST_DIR}/vcpkg-cmake-wrapper.cmake.in" "${CURRENT_PACKAGES_DIR}/share/lapack/vcpkg-cmake-wrapper.cmake" @ONLY)
    endif()

this (theoretically) currently does. [practically not since it is gated by the supports expression on the different platforms] The idea would be to move the wrapper of the supporting ports (lapacck-referen/openblas) somewhere else and move it only to the correct location in the meta port (blas/lapack)

Apr 22 '22 08:04 Neumann-A

But I already see that the forcing of the vendor theoretically works. Needs some further polishing but the general way should be clear now.

Apr 22 '22 08:04 Neumann-A

cc @ras0219-msft for review this PR.

May 05 '22 02:05 JackBoosY

@JackBoosY remove requires:author-response

Jul 14 '22 08:07 Neumann-A

@vicroms Can you please review again?

Jul 15 '22 02:07 JackBoosY

LINK : fatal error LNK1104: cannot open file 'f2c.lib'

Sep 30 '22 06:09 JackBoosY

Today I discovered that the LAPACK and BLAS CMake stuff doesn't work well with new gfortran on static triplets: Only with Fortran enabled, FindBLAS.cmake is successful. static lib blas needs static lib gfortran, and the latter only comes as a implicit link library for language Fortran.

theoretically you can bend the rules via vcpkg-cmake-wrapper in that case but it is one of the reason I would like to move away from gfortran on windows.

Jan 20 '23 21:01 Neumann-A

static lib blas needs static lib gfortran, and the latter only comes as a implicit link library for language Fortran.

why does static lib need static lib gfortran? It should always link dynamically against the fortran standard library because you probably will run into other issues otherwise.

Jan 20 '23 21:01 Neumann-A

It should always link dynamically against the fortran standard library because you probably will run into other issues otherwise.

Maybe, but what I observed was unresolved Fortran symbols when linking in C mode. (Apart from gfortran, the implicit link libs had quadmath and m. Last not least, I don't know what is pristine gfortran and what is msys2 packaging.

Jan 20 '23 21:01 dg0yt

~~blocked by #28734~~ (only if you want to count something being blocked by something already broken in master and only working in CI due to asset caching.)

Jan 27 '23 11:01 Neumann-A

blocked by #28734

Can you write it on top with a task? It will much easier to track.

[ ] https://github.com/microsoft/vcpkg/pull/28734

Mar 27 '23 12:03 talregev

Can you write it on top with a task? It will much easier to track.

Not necessary since the block is resolved by adjusting the ci.baseline. (since the port is already broken anyway)

Mar 27 '23 13:03 Neumann-A

Can you write it on top with a task? It will much easier to track.

Not necessary since the block is resolved by adjusting the ci.baseline. (since the port is already broken anyway)

Which PRs is blocking your PR? You have a waiting for different PR label.

Mar 27 '23 13:03 talregev

@Neumann-A If there isn't any PR that this PR are waiting for, please request to remove the depends on other PR label. other wise no one will review your PR.

Mar 27 '23 19:03 talregev

I agree that we need to recognize that the blas/lapack situation is just another alternative like openssl vs boringssl vs libressl, and the mechanism we have for that is overlay ports. I don't think pushing the versioning system in service of that role, as proposed here, is a good fit. I do like the presence of a test port to make sure the world is sane though; I'm going to try to staple that to https://github.com/microsoft/vcpkg/pull/21479/

Apr 14 '23 00:04 BillyONeal

I don't think pushing the versioning system in service of that role, as proposed here, is a good fit.

@BillyONeal I removed that part since that was optional to begin with

I'm going to try to staple that to https://github.com/microsoft/vcpkg/pull/21479

#21479 doesn't correctly move responsibility of the selection into the metaports for lapack/blas.

Apr 14 '23 06:04 Neumann-A

Will this be merged at some point? @Neumann-A

Jan 10 '24 13:01 sarlinpe

@sarlinpe: I am not responsible for getting stuff merged. I just propose changes via PRs.

Jan 10 '24 13:01 Neumann-A

Can you explain why windows-static is changed?

beacuse there should only be one BLAS implementation being provided. The problem in static builds is that lapack-reference cannot link openblas due to the current choice of the Fortran compiler being gfortran. This leads to the situation where both lapack-reference and openblas would provide blas symbols. Since lapack typically depends on blas and thus comes earlier on the link line only symbols from lapack-reference would be used any way. As such the switch just deals with the inconsistency and make lapack-reference the only symbol provider. The forcing of the blas vendor also helps with that.

Apr 03 '24 06:04 Neumann-A

This PR changes the selected BLAS/LAPACK implementation for some targets:

@BillyONeal I don't think that table is correct. Before it is basically undefined due to https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/FindBLAS.cmake?ref_type=heads#L394-L400 The code iterates through all possibilities until it finds an implementation.

Apr 03 '24 18:04 Neumann-A

This PR changes the selected BLAS/LAPACK implementation for some targets:

@BillyONeal I don't think that table is correct. Before it is basically undefined due to https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/FindBLAS.cmake?ref_type=heads#L394-L400 The code iterates through all possibilities until it finds an implementation.

Because it wasn't locked indeed it could have picked something else; I'm talking about what we expected to happen here.

Apr 03 '24 18:04 BillyONeal

Can you explain why windows-static is changed?

beacuse there should only be one BLAS implementation being provided. The problem in static builds is that lapack-reference cannot link openblas due to the current choice of the Fortran compiler being gfortran. This leads to the situation where both lapack-reference and openblas would provide blas symbols. Since lapack typically depends on blas and thus comes earlier on the link line only symbols from lapack-reference would be used any way. As such the switch just deals with the inconsistency and make lapack-reference the only symbol provider. The forcing of the blas vendor also helps with that.

Doesn't lapack-reference depend on gfortran itself? Why does using it instead fix the issue?

Apr 03 '24 20:04 BillyONeal

cc @BillyONeal: All good

Apr 06 '24 06:04 Neumann-A