"Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost> writes:
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)