Am Sun, 25 Mar 2018 21:28:32 -0500
schrieb Jason Bacon <outpaddling%yahoo.com@localhost>:
So I vote to get something started, experiment with it, and let it
evolve from what we learn.
OK, let's get started. I would like to install the 3 variants of
openblas:
lib/libopenblas.so
lib/libopenblas_pthread.so
lib/libopenblas_openmp.so
I also want to at least ship pkgconfig files:
lib/pkgconfig/openblas.pc
lib/pkgconfig/openblas_pthread.pc
lib/pkgconfig/openblas_openmp.pc
I introduced options.mk for wip/OpenBLAS for choosing the variant to
build. Since we now decided on installing multiple variants in
parallel and want to have dependencies, it seems more clean to me to
split this into distinct packages that share a Makefile.common and
common patches:
wip/openblas
wip/openblas_pthread
wip/openblas_openmp
Any reason to go for a combined package instead? I imagine that we'd
need to make at least libopenblas_openmp optional and that makes a
global choice of BLAS more complicated …
I think it is more manageable to have one package equal one BLAS lib.
Agreed? I see wip/wmx as a simple example of shared Makefile.common and
PATCHDIR. I'd cargo-code my way out of that …
We already got wip/cblas … I'd add wip/lapacke and build openblas with
NO_CBLAS=1 NO_LAPACKE=1. What we get from a BLAS package is
BLAS+LAPACK, which are the pieces that are accelerated. I am yet unsure
if
include/openblas$variant/openblas_config.h
lib/cmake/openblas$variant/OpenBLASConfig.cmake
lib/cmake/openblas$variant/OpenBLASConfigVersion.cmake
serve much purpose, but they wouldn't hurt, I guess. The
openblas_config.h tells the user some things about the build at hand. I
don't know if there is anyone using the CMake files (my personal
distaste for CMake may play a role here).
Alrighty then,
Thomas