Re: BLAS in pkgsrc: present and future

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

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

> Am Thu, 30 May 2019 07:59:42 -0500
> schrieb Jason Bacon <outpaddling%yahoo.com@localhost>:
>
>> We may have discussed this before and I missed/forgot it, but what is 
>> the reasoning behind creating a situation where a build fails? It's hard 
>> for me to imagine a user wanting a build to fail simply because the 
>> package is marked incompatible with their chosen BLAS implementation.
>
> My reasoning is this: If I want to be sure that things really use my chosen
> optimized BLAS, I want a package to fail to alert me to the fact that
> my choice does not work. I may have a GPU cluster and want all programs
> optimized to use a BLAS that runs on the GPU. I may be wrong in
> thinking that BLAS performance matters to all packages, but having this
> switch enables me to be pointed at those packages that don't accept my
> choice and prompt me to either fix the package or decide to switch to a
> different BLAS for that package (heck … is VAR.package an universal
> feature to override a global choice in mk.conf?).

I think that if a user sets PKGSRC_BLAS_PREFERRED to a list, then only
implementations from that list should be selected.  This means that if
there is no overlap with ACCEPTED for a package, that build will fail.
That seems very straightforward and likely what was intended.  If the
user wants some always-working fallback implementation, they can put it
at the end of PREFERRED.  Why the user wants this is not ours to
question; I cannot make the argument that anyone who wants this is
always wrong.

(which is a semi-lengthy way of agreeing with Thomas here)