Re: BLAS in pkgsrc: present and future

[Jason Bacon <outpaddling%yahoo.com@localhost>]

On 2019-05-31 03:48, Dr. Thomas Orgis wrote:
> 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?).
>
>
> Alrighty then,
>
> Thomas
OK, I have no objection to giving users both flexible and non-negotiable 
options.?? It would suggest being very explicit about it in the variable 
names, though:

So how about:

PKGSRC_BLAS_PREFERRED: User-controlled list of preferred implementations
PKGSRC_BLAS_EXCLUSIVE (or similar): User-controlled non-negotiable selection
PKGSRC_BLAS_ACCEPTED: Package-controlled list of usable implementations
_PKGSRC_BLAS_SELECTED (or similar): Internal selection based on the 
above three

Cheers,

?????? JB