Re: BLAS in pkgsrc: present and future

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

Am Fri, 31 May 2019 07:47:09 -0400
schrieb Greg Troxel <gdt%lexort.com@localhost>:

> [multiple variants in a dependecy tree]
> This is basically a mess.  It's not really about the selection code, but
> about the idea that linking in multiple implementations doesn't work,
> unless they have private namespaces.

It'll work … in interesting ways. Anyhow, it's a corner case as most
dependencies on stuff that uses BLAS are about wrapping BLAS in said
stuff (numpy, for example), or the user code simply does not use BLAS
itsef by chance.

When we settle on PKGSRC_BLAS_PREFERRED being an exhaustive list of all
_allowed_ implementations, one can set it to a single entry, be safe
and happy, dealing with some package not being able to build. If it is
not set at all … some packages that specifically allow only certain
implementations will pull them in, others will use the default netlib.
This doesn't have to cause issues as long as anyone adding
BLAS_ACCEPTED to a package keeps in mind the possible issues and
verifies that there is no dependency chain with possible confusion.

> Without.   I was off earlier.  There are
>   user-settable variables
>   package-settable variables
>   mk-set variables to be used in package makefiles
>   internal variables
> The PKGSRC_ prefix is generally most necessary on the first type, as
> they go in /etc/mk.conf.  We do not have a culture of prefixing PKGSRC_
> on mk-set variables and package-settable variables.

Thanks for that clarification. That matches what I saw so far.

> > BUILD_DEFS+=            CURSES_DEFAULT
> > BUILD_DEFS_EFFECTS+=    CURSES_TYPE  
> 
> That registers those variables and their value in the binary package, so
> it's available to be read later.

Hm. That sounds useful. So the first line shows the user choice
(mk.conf) and the second records the computed variables?

> I am expecting that you will write a wip/mk/blas.mk and we will iterate
> improving it, and once converged, hoist it to pkgsrc/mk/blas.mk.    Is
> that what you are expecting?

Yes. Let's say I'm a bit ahead of you already:

	wip/mk/blas.buildlink3.mk

This file exists since some time now;-) Jason and I are using it in wip
packages. The plan was now to bring it into shape to move to pkgsrc
proper in time for the next quaterly release.


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg