Gentoo Archives: gentoo-science

From: Danny van Dyk <kugelfang@g.o>
To: gentoo-science@l.g.o, sci@g.o
Subject: [gentoo-science] {blas,lapack}-config versus eselect
Date: Wed, 31 Aug 2005 21:25:33
Message-Id: 431620C9.5010901@gentoo.org
-----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@g.o>
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@g.o mailing list

Replies

Subject Author
Re: [gentoo-science] {blas,lapack}-config versus eselect Peter Bienstman <pbienst@g.o>