Hi there, I finally would like to implement a generic BLAS choice. I imagine a global variable specifying a default BLAS+LAPACK implementation to choose. Using that, thre would be generic mk/blas.buildlink3.mk mk/lapack.buildlink3.mk that contain logic to make a package include e.g. wip/openblas_pthread/buildlink3.mk if GLOBAL_BLAS_DEFAULT=openblas_pthread. The lapack.b3.mk is separate to, although most BLAS choices also provide LAPACK, to keep the dependencies cleaner. Also, one can imagine a separate lapack-whateverblas package that combines reference netlib LAPACK with a certain optimized BLAS. Anyhow … my first question is what is the preferred way to implement such a global choice? I imagine # any of: netlib atlas openblas openblas_pthread openblas_openmp BLAS_DEFAULT=openblas_openmp and mk/(blas|lapack).buildlink3.mk use that. Looking at mk/krb5.buildlink3.mk, I tentatively would not introduce a BLAS_ACCEPTED list for each package … the assumption is that any BLAS works, unless it doesn't. So perhaps a BLAS_REFUSED would be more fitting? Mind that the issues we talked about with especially parallel BLAS variants being troublesome, the trouble usually covered certain applications of installed packges, not the packages as such (certain user-supplied R/Octave/Numpy scripts that may or may not cause trouble). In case certain packages only work with certain BLAS, how would a per-package override look? Define an additional variable BLAS_TYPE that the package can set and which replaces BLAS_DEFAULT? Or is there already standard trickery to override values per-package? BLAS_DEFAULT.octave, like PKG_OPTIONS? I'm working with pkgsrc for some time now, but a good part of my knowledge is still following the cargo cult. Then, I might want to cover the whole picture including the wrapper libraries cblas and lapacke. A first step would one fixed decision (be it default or override) for cblas and lapacke to use a certain BLAS/LAPACK implementation and have any package that makes use of those wrappers indirectly depend on the respective BLAS. One could imagine creating variants of the wrapper libs for all BLAS implementations, but one could also go out to chop trees with a toenail clipper. Yeah, I hope it is fine when we focus on the case of one default BLAS/LAPACK to use, also for the wrappers cblas and lapacke, with certain packages that directly use a certain preferred BLAS being the special case. For now, I would like to have something to start with at all. I don't see many cblas users around, anyway. Lapacke doesn't even exist (did I miss it?). The situation I now aim for: - BLAS_DEFAULT machinery with mk/blas.buildlink3.mk and mk/lapack.buildlink3.mk. - math/cblas and math/lapacke packages (all pulled from lapack tarball to stay consistent), using BLAS_DEFAULT - math/octave, math/R using BLAS_DEFAULT - update of lapack to 3.8.0, but after everything else is in place and checking if our BLAS suppliers bundle the same version Observe the last point: We need to ensure that every offered LAPACK implementation agrees on the API. Version 3.8 adds things. If a BLAS library does no timely updates in a certain timeframe, we should omit the included LAPACK and make a library using netlib's LAPACK linked to the optimized BLAS in pkgsrc. That either needs separate BLAS libs or just some Makefile hackery to replace a supplied copy of LAPACK. Now, can someone comment on the proper syntax approach before I start copying stuff from other mk/*.buildlink3.mk? Alrighty then, Thomas PS: Please include my math/cgal patch (or equivalent) in CVS trunk … we agreed long ago that the version bump is needed. -- 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