Re: [gentoo-science] blas/lapack status

[Adam Piątyszek]

Dear Sebastien, all,

* Sebastien Fabbro [2006-03-20 17:54]:
[...]
> * eselect: although eselect seems the way to go, it not yet fully
> functional. As I was working on the mkl ebuild, I found out it is not
> possible to add a new blas/lapack implementation without changing the
> eselect sources. As an example, mkl-7.2 is supported, but not in
> portage, and outdated. Also eselect blas/lapack do not yet provide a
> mechanism to show library directories and include directories. Something
> like "eselect blas show cflags"? Am I missing something?

I encountered similar limitation when I was preparing an ebuild for 
cblas-reference package (see the following bug-report: 
http://bugs.gentoo.org/show_bug.cgi?id=122958 )

> * Should we really keep those obsolete packages:
>  - sci-libs/atlas: now decomposed as sci-libs/blas-atlas and
> sci-libs/lapack-atlas
>  - sci-libs/blas: redundant with sci-libs/blas-reference
>  - sci-libs/lapack: redundant with sci-libs/lapack-reference

I agree with you Sebastien.
Gentoo Devs: Are there any packages in portage that still use the old 
obsolete atlas/blas/lapack as their dependencies?

> * cblas/clapack: as mentioned in a previous post, at least a
> virtual/cblas could help (as well as a cblas-reference) ebuild.

Are you refering to my post at gentoo-science: "CBLAS support in Gentoo" 
from February 17th, 2006?
Agree one more time: virtual/cblas will be helpful for dependencies in 
"itpp" package, for instance.

> I am ready to help some devs on those issues if any interested.

I am also ready to help with some limited testing and providing ebuilds/fixes.

BR,

/ediap

-- 
-=#=-  Adam Piątyszek - "ediap"    -=#=-  Linux ID: #204648         -=#=-
-=#=-  ediap (at) et.put.poznan.pl -=#=-  JID: ediap (at) chrome.pl -=#=-
-=#=-  http://ediap.prv.pl/        -=#=-  GG: 1157376               -=#=-
-=#=-  PGP key ID: 0x341E22F0      -=#=-  ICQ: 3303291              -=#=-




-- 
gentoo-science@g.o mailing list