Bugzilla Bug 81520

I suggest that if atlas is listed in the USE flags, that Numeric should depend
on lapack-atlas and blas-atlas. I suggest that sci-libs/atlas is not a good
alternative, because it does not have a full lapack implementation.

The setup.py file should be modified, I'll post a patch.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Created an attachment (id=50930) [details]
patch for setup.py to recognize atlas on gentoo

Here is the setup.py patch for an ebuild to recognize lapack-atlas. I dont have
experience writing ebuilds, but I will try to propose a new one that depends on
lapack-atlas if USE="atlas". This patch would be applied instead of the
existing patch, again if USE="atlas".

Created an attachment (id=50945) [details]
patch for numeric to recognize atlas

successfully built numeric with this patch, and the following ebuild...

Created an attachment (id=50946) [details]
proposed ebuild for numeric-23.7-r1

I was able to link numeric-23.7 to atlas-tuned blas and lapack using this
ebuild and patch 50945. If USE="atlas", then lapack-atlas is required.

Hi Darren!

Ok, what I don't like on this idea is the following: We currently have a working
system to switch between different BLAS and LAPACK implementations. So it makes
no sense to apply this patch to circumvent the current system.

A much better patch would make it look like this:

library_dirs_list = ['/usr/lib/']
libraries_list = ['lapack', 'cblas', 'blas', 'atlas', 'g2c']

This way, any user of numeric could switch between the implementations using
blas-config and lapack-config.

Created an attachment (id=50997) [details]
updated patch to play nice with blas-config and lapack-config

The use flag in the above ebuild is in question, but this patch is offerred as
suggested in the last comment.

[As a side note: please submit always patches against ebuilds you want to be
modified. This eases the devs job twice: 1st) he sees the actual differences,
2nd) he can commit w/o problems even if other parts of the ebuild have been
altered in between submission and commit. ;-) ]

Darren, as we already talked about on gentoo-science ML, we need to remove
the "atlas" USE flag from your ebuild submission...

@Python-herd: I'd like to see this in the tree. Mind if I commit it myself and
add the Scientific Herd to the metadata ?

--- numeric-23.7.ebuild 2005-02-16 13:01:25.403085728 +0100
+++ numeric-23.7-r1.ebuild      2005-02-16 13:01:08.422667144 +0100
@@ -11,19 +11,21 @@
 SRC_URI="mirror://sourceforge/numpy/${MY_P}.tar.gz"
 HOMEPAGE="http://www.pfdubois.com/numpy/"

-IUSE=""
+IUSE="lapack"
 SLOT="0"
 KEYWORDS="~x86 ~ppc ~sparc ~alpha ~hppa ~amd64"
 LICENSE="as-is"

 # 2.1 gave sandbox violations see #21
-DEPEND=">=dev-lang/python-2.2"
+DEPEND=">=dev-lang/python-2.2
+       lapack? ( virtual/lapack )"

 src_unpack() {
        unpack ${A}

        cd ${S}
        epatch ${FILESDIR}/${P}.patch
+       epatch ${FILESDIR}/${P}-lapack.patch
 }

 src_install() {

Thats excellent, thank you Danny.

One final comment, the homepage for Numeric is now:

http://numeric.scipy.org/

It should be reflected in the ebuild.

The Gentoo Scientific overlay in http://gentooscience.org contains an updated
ebuild of numeric allowing lapack and also makes some fixes.

The ebuild in the gentooscience.org overlay fixes a decent number of numeric
problems. From the ChangeLog:

  +files/numeric-arrayobject.patch, +files/numeric-lapack.patch,
  +numeric-24.2-r1.ebuild: fixed a memory leak, and added the possibility
  to compile linear algebra with installed blas/cblas/lapack.
  Tested against gcc41 and gcc34 on amd64, x86. Added longdescription
  in metadata.xml. Closes bugs #81520 and #114885.

May be it would be worth a bump in the main tree?

added lapack support in numeric-24.2-r2, now in cvs.