Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-science
Navigation:
Lists: gentoo-science: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-science@g.o, sci@g.o
From: Danny van Dyk <kugelfang@g.o>
Subject: {blas,lapack}-config versus eselect
Date: Wed, 31 Aug 2005 23:27:37 +0200
-----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:
Re: {blas,lapack}-config versus eselect
-- Peter Bienstman
Navigation:
Lists: gentoo-science: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Positions available in a gentoo-based research lab
Next by thread:
Re: {blas,lapack}-config versus eselect
Previous by date:
Positions available in a gentoo-based research lab
Next by date:
Re: {blas,lapack}-config versus eselect


Updated Jun 17, 2009

Summary: Archive of the gentoo-science mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.