Re: I want to merge some BLAS updates to get things in a future-proof shape before the branch. Please review.

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

Am Sat, 12 Jun 2021 07:25:35 +0000
schrieb nia <nia%NetBSD.org@localhost>: 

> We're currently in "careful mode" in preparation for a freeze.

I know. You can say 'stop'. Thing is, I'd like to avoid perpetuating
the situation where we mix netlib cblas and lapacke with optmized
builds by shipping it also in the next stable branch. I had to realize
that it is a really unusual thing not to enable the C interface in the
optimized library instead. This is what projects seem to expect. Case
in point: On

	https://github.com/Reference-LAPACK/lapack/issues/461

(most recent comments)

I describe how numpy uses its own CBLAS header that actually does not
match the netlib ABI (size_t vs int or long). This might be a bug that
should be fixed in any case, and it is much more satisfying for me to
work on this in the framework as it should be for the future.

The actual change I am proposing is not that heavy, as it only affects
users of cblas or lapacke, of which there are not many besides numpy:

$ find . -type f | xargs grep cblas/buildlink 2>/dev/null
./math/py-numpy16/Makefile:.include "../../math/cblas/buildlink3.mk"
./wip/gemma/Makefile:.include "../../math/cblas/buildlink3.mk"
./wip/plink2/Makefile:.include "../../math/cblas/buildlink3.mk"
./wip/plink/Makefile:.include "../../math/cblas/buildlink3.mk"

(py-numpy itself not on this is as I am working on it locally)

I can test these.

The other dependents get libblas.so and liblapack.so or libopenblas.so
like before, usage of blas.bl3 does not change for them.

If this is not deemed safe enough for the careful mode, I'll have to
hold back. But I hoped to install the first pkgsrc tree for my users
after getting more heavily involved from the next quarterly release.
Would be nice not to start this right away with patching on the very
stuff I started with.

What I will add in the time after the branch will some handling of MKL,
which i have as a local patch on one system.


Alrighty then,

Thomas

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