Re: BLAS in pkgsrc: present and future

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

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

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg