Re: BLAS in pkgsrc: present and future

[Greg Troxel <gdt%lexort.com@localhost>]

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

> 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.

ok, but generally we set something like _PKGSRC_BLAS_TYPE, to keep
internal variables separate from user-settable variables.
>
> 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).

I wonder if it would be simpler to have a default value of
PKGSRC_BLAS_PREFERRED, if not set by the user.   Which amounts to the
same thing, but avoids case 4.

> The package uses PKGSRC_BLAS_TYPE for the build.

(same comment about a different variable)


(Note that I think my comments in this mail are very minor.)