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.