[lapack] add metaport lapack to switch lapack impl with an overlay

[Neumann-A]

In preparation to add netlibs lapack-reference from #11454

[cenit]

in order to be ready even better, do you have any idea on how to handle osx inside lapack-select?
Whenever we will have lapack-reference, it would be better to use it instead of Accelerate Framework!
This will make it very easy to enable it for all lapack-depending ports

[Neumann-A]

@cenit what about all those openblas (!osx)? Can they also be removed since lapack will depend on blas?

[Neumann-A]

in order to be ready even better, do you have any idea on how to handle osx inside lapack-select

@cenit see latest commit. You basically need a select feature with a build-depends which has the platform conditions. The feature is required to not always force the dependency.

[cenit]

@cenit what about all those openblas (!osx)? Can they also be removed since lapack will depend on blas?

OpenBLAS has improved a lot and we can use it on vcpkg now maybe. For sure, it's not like clapack (which is not acceptable on osx)

[cenit]

in order to be ready even better, do you have any idea on how to handle osx inside lapack-select

@cenit see latest commit. You basically need a select feature with a build-depends which has the platform conditions. The feature is required to not always force the dependency.

Convoluted but effective. Nice!

[Neumann-A]

OpenBLAS has improved a lot and we can use it on vcpkg now maybe. For sure, it's not like clapack (which is not acceptable on osx)

@cenit: The question was more is at a real openBLAS dependency or is it a indirect dependency due to LAPACK which should not be listed in Build-Depends.

[cenit]

We don't want blas functions from lapack-reference, so we should disable internal blas and add a real dependency on openblas. Similarly, the cblas feature should disappear from lapack-reference, since the C API for blas will be provided by openblas.
Each one for the best part they provide :)

[Neumann-A]

We don't want blas functions from lapack-reference

Yeah that is clear. The question was if the ports actually use BLAS functions or if they only use LAPACK functions and thus only indirectly depend on BLAS.

[cenit]

Ah now I understand what you mean
ports depending on openblas (!osx), clapack (!osx) in fact might look suspicious, because depending on clapack (!osx) should have been enough, since clapack then internally uses blas, provided for us by openblas. But it wouldn't be so strange if they were using lapack for something, but also blas for other things, independently of their relationship, and thus correctly depending on both anyway.
I would have to check their sources. A quick way would be to scan for find_package(BLAS) and find_package(LAPACK). If only the latter, then the former would be an unnecessary direct dependency

[Neumann-A]

Doesn't seem to depend on openblas or lapack directly.

[strega-nil]

@Neumann-A is there a reason that you're depending on lapack-select[core] as opposed to just lapack-select in the dependencies?

[Neumann-A]

@strega-nil: depending on lapack-select always means lapack-select[core,default] which forces the default feature as a build dependency. So lapack-select[core,otherfeature] does not fulfill lapack-select

[JackBoosY]

@strega-nil See #11602, use core in Build-Depends doesn't work currentlly.

[strega-nil]

@Neumann-A I see... so we want the lapack-select dependency to be fulfilled when the user installs lapack-select with her own chosen feature... hrmm...

[Neumann-A]

@strega-nil vcpkg still chooses a default for the user if it is not explicutly specified. If you ask why something like this is necessary just take a peek in cmakes FindLAPACK.cmake

[strega-nil]

Right, yeah, I'm just thinking about how best to do this, since at some point I'm hoping that we stop installing default features for dependencies listed with core.

[ras0219]

Features are designed to be additive, not exclusive; they shouldn't be used to model "exactly-one-of" -- they model "Any subset of". Since this is an "exactly-one-of", it isn't a good fit for features.

Instead, for this situation, our current best approach is to use overlay ports. In this approach, there is an intermediate port exactly like in this PR, ideally named like the interface (perhaps just lapack and just blas). That port is an empty "alias" for the default implementation:

# CONTROL
Source: lapack
Version: 0
Description: Metapackage for packages which provide LAPACK
Build-Depends: clapack (!osx)

# portfile.cmake
set(VCPKG_POLICY_EMPTY_PACKAGE enabled)

Users can then redirect this metapackage by copying the port, replacing the Build-Depends: however they like, and using --overlay-ports=.

[strega-nil]

cc @ras0219 this look good to you?