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 -- Dr. Thomas Orgis Universität Hamburg RRZ / Basis-Infrastruktur / HPC Schlüterstr. 70 20146 Hamburg Tel.: 040/42838 8826 Fax: 040/428 38 6270
Attachment:
smime.p7s
Description: S/MIME cryptographic signature