Am Wed, 29 May 2019 17:12:18 -0500
schrieb Jason Bacon <outpaddling%yahoo.com@localhost>:
I think we need a way to override BLAS_TYPE gracefully, perhaps by
building with the first variant in BLAS_ACCEPTED when none of them match
BLAS_TYPE?
Sure. Since they all can be installed at the same time, this does make
sense. We had this discussion on variable names and semantics. Is this a conclusion we can agree on?
mk.conf variables:
PKGSRC_BLAS_PREFERRED: a list of implementations the user prefers
PKGSRC_BLAS_TYPE: hard override to choose exactly one
package variables:
PKGSRC_BLAS_ACCEPTED: implementations that the package works with
Then, blas.buildlink3.mk uses this logic:
1. If PKGSRC_BLAS_TYPE is set, use that and error out if it is
not in the list PKGSRC_BLAS_ACCEPTED.
2. If PKGSRC_BLAS_PREFERRED is set, match against PKGSRC_BLAS_ACCEPTED
and use the first match to set PKGSRC_BLAS_TYPE. If there is no
match, the first entry in PKGSRC_BLAS_ACCEPTED is used.
3. If only PKGSRC_BLAS_ACCEPTED is set, use the first in that to set
PKGSRC_BLAS_TYPE.
4. Otherwise, resort to a default (netlib).
The package uses PKGSRC_BLAS_TYPE for the build.
Alrighty then,
Thomas