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>]

Hm,

nobody explicitly said 'stop'. So I'll merge what I announced and will
adapt/test the two NumPy packages. Especially, since …

Am Sat, 12 Jun 2021 14:54:01 +0200
schrieb "Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>: 

> 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)

… all the other cblas-using packages are in WIP anyway.

To make things more funny: NumPy doesn't even use headers from CBLAS at
all. So there is nobody in current CVS who cares about the BLAS headers
that I replace.

This point in time is early enough to do this change, where it doesn't
have much impact anyway. We'll move forward with packages that might
want to use more BLAS stuff, with C API, in the future. For example,
stuff that explicitly uses gslcblas comes to mind. The footprint of
BLAS infrastructure is going to grow.


Alrighty then,

Thomas

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