Re: BLAS in pkgsrc: present and future

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

On 2019-04-25 03:55, Dr. Thomas Orgis wrote:
> Am Wed, 24 Apr 2019 09:18:58 -0500
> schrieb Jason Bacon <outpaddling%yahoo.com@localhost>:
>
> > I think the system should choose the first implementation listed in
> > [PKGSRC_]BLAS_PREFERRED in all cases except where it conflicts with
> > [PKGSRC_]BLAS_ACCEPTED, in which case is chooses the first in ACCEPTED.
> Sounds reasonable. Is this current practice for other such choices?
>
> So, this would mean, mk.conf can contain
>
> PKGSRC_BLAS_PREFERRED = foo bar
>
> for the logic indicated above, but also
>
> PKGSRC_BLAS_TYPE = foo
>
> to really only allow one implementation being used (and have some
> packages possibly being incompatible with this choice). Right?
Correct.?? I just committed wip/gemma as an interesting test case. It 
contains some openblas-specifics that could probably be patched out, but 
for now I set BLAS_ACCEPTED=openblas in the pkg Makefile.

Currently build is killed unless I set BLAS_TYPE=openblas somewhere.

You can also try wip/plink2, which I just updated to respect ${BLAS_LIBS}.
> > causing serious problems.?? One of my genomics apps, plink, currently
> > dumps core when built with openblas and works fine with netlib.
> Is this with any openblas variant or only a parallel one? I'd consider
> this a serious bug to investigate, if it is the serial one at least.
I've never tried a parallel openblas.?? I will retest with the latest 
wip/openblas, though, in case anything has changed recently.
> > I don't think there's much chance of collisions using BLAS_*, but it is
> > theoretically possible that an application could use something like
> > BLAS_PREFERRED with different semantics.?? Using PKGSRC_BLAS_* might be
> > better just for the sake of self-documentation, so people know at a
> > glance that they're looking at a PKGSRC knob rather than an upstream knob.
> Are we talking about the variables to be set in mk.conf now or also
> about the resulting variables blas.bl3.mk sets for the package?
> Everything shall have PKGSRC_ prefix? Also BLAS_LIBS?
>
> What would an upstream knob look like in a pkgsrc Makefile? I mean ???
> all variables there are pkgsrc variables, the upstream stuff is only
> explicitly set via MAKE_ENV etc. What's a possible case of confusion? I
> do see a possible conflict with the pkgsrc Makefile defining variables
> for local use, sure. But what's upstream here?
Upstream = what's in the developer's distribution, i.e. what's under 
"work" after extract.

I'm saying it's theoretically possible, though unlikely, that the 
developers might use something like BLAS_TYPE in their own build system 
or source code, with a different meaning than what's defined in 
blas.buildlink3.mk.

Hence the PKGSRC_ prefix might same someone a headache someday.

Cheers,

?????? JB