Re: BLAS in pkgsrc: present and future

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

Jason Bacon <outpaddling%yahoo.com@localhost> writes:

> I think we should document the most common pitfalls in
> mk/blas.buildlink.mk, e.g. the possibility of introducing multiple
> BLAS libraries into a link via dependencies or dependencies.
>
> We can offer the following advice to developers and users to avoid
> this issue:
>
> 1. Set BLAS_TYPE in mk.conf if possible, rather than in packages or on
> the command-line while building individual packages.

pkgsrc has long had a concept, not necessarily clearly mapped to
variable namespaces, of "package-settable variables" and "user-settable
variables".  I think that we need to be very clear about each, to the
point that it's a pkglint error if they are set in the wrong place.  The
place to document this is probably mk/blas.buildlink.mk first, as many
such files have a sections about user-settable, package-settable, and
internal variables, often feeling like

BLAS_PREFERRED= #user
BLAS_ACCEPTED= #package
_BLAS_VERSION= # internal

There is a question of having PKGSRC_ prefixes, as seems to be the
modern trend.

If the intent is that any given pkgsrc instance can have one and only
one blas type, then PKGSRC_BLAS_TYPE is appropriate.  If they don't
conflict, and it's sane to have multiple - because perhaps some program
only supports one kind - then we need PKGSRC_BLAS_PREFERRED to set the
type to be used, with it perhaps being a list of what we are willing to
build, with each package choosing the first of the PREFERRED list taht
is in the package's ACCEPTED.  That's complicated, so haciving a single
PKGSRC_BLAS_TYPE may be better.


> 2. Be as broad as possible with BLAS_ACCEPTED in package Makefiles.

Agreed.