[gentoo-science] {blas,lapack}-config versus eselect

[gentoo-science] {blas,lapack}-config versus eselect

[Danny van Dyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

[Sorry for my long absence, but I had to prepare for an important and
difficult exam that took me more time than I had whished it had.]

I'd like to get some input from you on my work on eselect[1] modules
replacing {blas,lapack}-config. To give you an impressions on the
differences between these modules and the current config tools, here
comes a short synopsis.

*-config rely on short bash scripts which are installed alongside the
packages. To switch between LAPACK and BLAS implementations, the
appropriate config tool sources the script and runs setup(). This is
error prone, as the get_libdir() problem has shown :-/

The corresponding eselect modules approach the setup differently. Each
packages that provides either BLAS or LAPACK has a dedicated check_*()
and setup_*() routine inside the module. For example, ACML has these
functions inside blas.eselect:

# check_* $libdir
# implementation specific check functions
check_ACML() {
	# libacml.so provides C/C++ and FORTRAN 77 support
	[[ -f ${1}/libacml.so ]] && echo "C F77"
}
[snip]
# is_active_* $lib
# return 0 if $lib points to an active BLAS implementation of profile *
is_active_ACML() {
	[[ -L ${1} ]] || return 1
	local lib=$(readlink -sn ${1})
	[[ $(basename ${lib}) == libacml.so ]] \
		&& return 0
	return 1
}
# setup_* $libdir $profile
# Implementation specific activation/setup functions
setup_ACML() {
	if [[ ${2} == C ]] ; then
		ln -sf ${1}/libacml.so ${1}/libcblas.so
		ln -sf ${1}/libacml.so ${1}/libcblas.so.0
		ln -sf ${1}/libacml.a  ${1}/libcblas.a
	elif [[ ${2} == F77 ]] ; then
		ln -sf ${1}/libacml.so ${1}/libblas.so
		ln -sf ${1}/libacml.so ${1}/libblas.so.0
		ln -sf ${1}/libacml.a  ${1}/libblas.a
	else
		die "Illegal profile: ${2}"
	fi
}

The eselect modules currently include all features (beside support for
threaded-atlas) that blas-config and lapack-config provide. Further, the
eselect modules are prepard for BLAS/LAPACK implementations in other
programming languages (think of a FORTRAN 90/95 only implementation).

If nobody objects, I'd like to move all packages in the tree to PDEPEND
on eselect instead of {R}DEPENDing on {blas,lapack}-config.

Danny

[1] http://www.gentoo.org/proj/en/eselect
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDFiDIaVNL8NrtU6IRAubtAJ9fHKroXyBuGPno7R/4FBycAirorwCdGi/5
S6ZvAlZVRfVQrOkj0ehsNF0=
=1dNv
-----END PGP SIGNATURE-----
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] {blas,lapack}-config versus eselect

[Peter Bienstman]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

On Wednesday 31 August 2005 23:27, Danny van Dyk wrote:

> If nobody objects, I'd like to move all packages in the tree to PDEPEND
> on eselect instead of {R}DEPENDing on {blas,lapack}-config.

Sounds like the way to go. This will probably delay marking lapack-atlas and 
friends as stable a bit, but that's not a big issue.

In related news, I've converted sys-cluster/hpl to virtual/lapack. This leaves  
scilab as the last package that still requires the old infrastructure.

Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]