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

Hi,

I just pushed that to WIP and would like to get feedback on the changes
therein that I want to merge to CVS soon. Main points that change the
current packages in math:

- move of cblas/lapacke headers to include/netlib (with symlink to include)
- fixing of math/cblas and math/lapacke to use netlib BLAS
- math/openblas* includes C interfaces (so does not need separate cblas
  and lapacke)
- possibly a merge of wip/mk/blas64.buildlink3.mk with
  mk/blas.buildlink3.mk, but maybe only two files next to each other
  (opinions?)

The *64 packages are new and don't disturb anyone.

More prose in the commit blurb:

commit f3668144b0bdad5f5f3e3dc3aef000d6716d5264 (HEAD -> master, origin/master, origin/HEAD)
Author: Dr. Thomas Orgis <thomas.orgis%uni-hamburg.de@localhost>
Date:   Thu Jun 10 19:51:22 2021 +0200

    blas64, lapack64, cblas*, lapacke*, openblas*, mk/blas64.bl3: fixup and 64 bit BLAS
    
    This prepares for 64 bit index BLAS libraries alongside 32 bit ones. In preparation
    of better support for vendor BLAS libraries, I had to realize that you better
    use the C interfaces supplied by them, not the netlib one strapped on. A simple
    reason of practicability: The vendor blas libraries, like openblas, like to
    ship all symbols in one library, so you get them whether you want it or not.
    
    The netlib reference pacakges are still all separate packages for the separate
    libraries, since this is instructive and helps keeping things small when you
    do not need all of them. The installation location of the headers is now in
    a subdirectory to be able to have 32 and 64 bit variants independent. The 32 bit
    ones are linked to ${PREFIX}/include to keep the old picture. We could be brave
    and remove those, but there is some value in a build just trying -lcblas and
    
    to be happy.
    
    The blas64.buildlink3.mk conflicts with blas.buildlink3.mk to avoid hazardous
    combination of the same symbols with differing ABI. The contents of blas.bl3
    will be updated to behave the same way on merging in. One might consider merging
    the identical parts of the files, but then, this might be not worth it.
    
    Another idea is to have it all on one blas.bl3 and have a variable to switch
    between 32 and 64 bits. BLAS_INTERFACE64=yes, perhaps? BLAS_ILP64 seems to
    confuse people a lot;-) That way, a mix of differing settings would also not
    be possible.
    
    I would like to merge this before the next branch … let's see. The 64 bit stuff
    is pretty safe right now as nothing else uses it, but I intend to make
    py-numpy, octave, R etal. use the 64 bit CBLAS on 64 bit platforms.
    That switch itself will need some time to settle, I guess, but having the 64 bit
    BLAS in main is a prerequisite to do that without too much hassle.


Some context:

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

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