Am Wed, 17 Apr 2019 20:26:15 -0400
schrieb Greg Troxel <gdt%lexort.com@localhost>:
pkgsrc has long had a concept, not necessarily clearly mapped to
variable namespaces, of "package-settable variables" and "user-settable
variables".
Right now, there is BLAS_TYPE as user-settable (mk.conf) and the final
variable set for the build, the blas.bl3.mk logic only filling it in.
BLAS_ACCEPTED is per-package. Then, there's BLAS_LIBS, LAPACK_LIBS
being set, and the internal _BLAS_PACKAGE and _BLAS_TYPE (and
_BLAS_TYPES, as implementation detail).
BLAS_PREFERRED= #user
BLAS_ACCEPTED= #package
_BLAS_VERSION= # internal
There is a question of having PKGSRC_ prefixes, as seems to be the
modern trend.
So, we are discussing renaming of BLAS_TYPE to PKGSRC_BLAS_TYPE, or
indeed replacement by PKGSRC_BLAS_PREFERRED?
Since we have BLAS_ACCEPTED, I guess one should keep the option of a
second choice if the main BLAS is not compatible. So, I'm for extending
the blas.bl3.mk to support PKGSRC_BLAS_PREFERRED.
But the result of the matching with BLAS_ACCEPTED (without PKGSRC_
prefix — or do we want to plaster package Makefiles with PKGSRC_
everywhere?) shall still be called BLAS_TYPE? Or _BLAS_TYPE?
I'd like to keep BLAS_LIBS and LAPACK_LIBS, as these are not uncommon
to be the actual environment variables that you need to set for BLAS
choice in builds.
I wonder about the semantics of PKGSRC_BLAS_PREFERRED. Does ‘prefer’
imply that any BLAS not on the list is not acceptable? Or should a
package that does not support any of the preferred BLAS get built with
another default?
Do we actually have much of a problem with namespace collision in the
Makefiles? In theory, it's a mess. But is it in practice? Do we have a
consensus to prefix all new variables in included Makefile fragments
with PKGSRC_? Or do we just continue to handle conflicts as they arise?
Alrighty then,
Thomas