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 attachment 50930 [details, diff] 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 attachment 50945 [details, diff] patch for numeric to recognize atlas successfully built numeric with this patch, and the following ebuild...
Created attachment 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 attachment 50997 [details, diff] 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.