[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Bring BLAS into pkgsrc, pt. II
Am Sun, 21 Jul 2019 10:09:04 -0500
schrieb Jason Bacon <outpaddling%yahoo.com@localhost>:
> 1. As I mentioned earlier, I think the variable names could be more
> explicit to avoid confusion between what goes in mk.conf and what goes
> in the pkg Makefile.
The variable with PKGSRC_ prefix goes into mk.conf. The others are for
the Makefile. That's what I understood from the earlier discussion (no
tradition of actually prefixing variables in package Makefiles with
I agree that 'preferred' does not convey the actual meaning.
> PKGSRC_BLAS_PREFERRED => PKGSRC_USER_BLAS_ACCEPTED
> BLAS_ACCEPTED => PKGSRC_PKG_BLAS_ACCEPTED
I don't like four words in the variable name. Too verbose.
Right now we have those similar variables in the Makefiles:
$ find . -name Makefile | xargs grep _ACCEPTED | grep -v '#' | cut -f 2 -d : | cut -f 1 -d = | sort -u
So, there is the example of two-word BDB_ACCEPTED and KRB5_ACCEPTED
that match BLAS_ACCEPTED. But the majority is three-word names, mostly
with VERSION in the middle. That's not the right word here, but we
BLAS_ACCEPTED => BLAS_TYPES_ACCEPTED
Then the resulting BLAS_TYPE matches that wording. And actually, we can
use that for the user variable, too:
PKGSRC_BLAS_PREFERRED => PKGSRC_BLAS_TYPES
That may make more clear that it's about an exhaustive list of BLAS
implementations, not just a preference. So we'd have:
PKGSRC_BLAS_TYPES in mk.conf
BLAS_TYPES_ACCEPTED in Makefile
BLAS_TYPE, BLAS_LIBS, LAPACK_LIBS to be used by Makefile
> 2. I think we need to insert a step 1.5 into the process:
> Test/patch all existing dependent packages against the new system before
> committing the new blas and lapack packages.
Well, of course you need testing and fixing, but the import of
wip/lapack basically means a version update to 3.8.0 for dependent
packages. There is no fundamental change in what is provided. Checking
for one math/blas user that the change of now depending indirectly on
math/lapack causes no trouble makes sense.
What we need to check is the upgrade path. Will it cause trouble that
we now got liblapack.so.3 instead of liblapack.so.4? Things need a
rebuild. Or should be include a hacky symlink after all?
Hm, I am not at my workstation where my access key for pkgsrc-wip is
stored. I just noticed that wip/blas should have an empty PLIST. It's
not installing anything. I guess this causes no trouble as the check is
not done for the meta package, but it looks unclean.
> duplicate the affected packages in wip with necessary patches.
I am positive that we won't need proper patches for math/lapack or
math/blas usage. But of course one should check. We need people to
rebuild the packages, though. So … at least PKGREVISIONS?
Dr. Thomas Orgis
HPC @ Universität Hamburg
Main Index |
Thread Index |