As I really would like to get going implementing something, people are waiting for updated software … Am Tue, 27 Feb 2018 09:18:05 -0600 schrieb Jason Bacon <bacon4000%gmail.com@localhost>: > As long as I can make a dependent package use any of the available blas > implementations and I can install > them all on the same cluster, I'm happy. Is it enough for you to be able to override a global default in your install of a dependent package (mk.conf) or do we have a hard disagreement here about the depending packages defaulting to different BLAS libs? I hope I made my point clear in the other lengthy mails. Regarding compatibility of different BLAS implementations to dependent packages: Disregarding parallelization choices, where we should never impose a multithreaded default on the user, IMHO, as it depends to much on the use case after all (a slight change from my initial opinion, considering that HPC installations are _not_ the norm), any compatibility issues are about telling the package to use the correct library name. The standards for BLAS and LAPACK API are so stable, with straight-forward mathematical correctness tests, that we really should not consider some package being incompatible with a certain BLAS once we hacked a generic choice of BLAS LDFLAGS into the build, which most builds explicitly offer. Exactly because the long-term practice in HPC is to provide your BLAS linking flags for the system at hand. If we still disagree, I am eagerly awaiting your arguments to the contrary, but I would prefer finally getting on with adding the switches to pkgsrc and building a refreshed software stack with consistent BLAS for our users. I'll forget about openblas cmake files 'n stuff for now. I'll happily start with the openblas-devel package and add the second parallel variant to it. Alrighty then, Thomas -- Dr. Thomas Orgis Universität Hamburg RRZ / Basisinfrastruktur / HPC Schlüterstr. 70 20146 Hamburg Tel.: 040/42838 8826 Fax: 040/428 38 6270
Attachment:
smime.p7s
Description: S/MIME cryptographic signature