That said, one of the great things about using SciPy instead of matlab is that it's python. Except all the prebuilt binaries (to my knowledge anyway) use at newest python 2.5. Again, probably not a problem for most, but I use the nice socket library (amongst other things) that's been improved significantly in python 2.6. So for a while I had my SciPy python and my everything else python and every so often I would make another attempt building SciPy for py2.6 on my mac to integrate the two and every time it would defeat me.
Until yesterday.
So I'm going to attempt to fully document the process as I've now done it on 2 similar machines (home & lab) and now that I've figured out the tricky bits it seems fairly easy to reproduce. These instruction were followed on 1 - 2 year old intel based macs running 10.5.8. (Note these instructions don't touch on installing the other pieces of standard SciPy setup, ipython and pylab/matplotlib as I've never had much trouble getting these to build. I believe the easy_install process works for both, mostly)
- (optional) If you don't want to build universal python modules remove "-arch ppc -arch i386" from the BASECFLAGS and the LDFLAGS in the python library Makefile, which should live somewhere around here: /Library/Frameworks/Python.framework/Versions/Current/lib/python2.6/config/Makefile
- If you don't already have xCode 3.1.3 and the associated developer tools you need to get it for apple's custom build of gcc 4.2 (it's not the version that comes with most box copies of 10.5). Download and install a fresh copy of the Apple Developer Tools. You can get SciPy to compile with other variants of gcc 4.2 or greater (from MacPorts for instance) but they don't support apple specific options, which are very helpful in other situations.
- Download and install gFortran as a patch to the apple gcc from att research. Why apple doesn't leave gfortran in gcc I don't know, but they don't and we need it. It's critical you use this fortran compiler as other variants of gfortran or g77 seem to cause errors.
- Download and install UMFPACK and AMD from SuiteSparse. The easiest way I've gotten through this is to download the entire SuiteSparse and then do the following:
- Modifiy the package wide config makefile found at SuiteSparse/UFconfig/UFconfig.mk by uncommenting the Macintosh options (currently lines 299 - 303)
- In order to only compile the 2 packages we also need to modify the high level makefile (SuiteSparse/Makefile) by commenting out the references to the other packages under the default call (currently lines 10, 12-17, 19-24).
- run make while in the SuiteSparse dir
- because it would be too easy if SuiteSparse actually had an install routine, we have to install the just compiled libs ourselves. This is how I did it, though you can stick all these bits wherever you like as long as the python compiler and linker will see them:
$sudo install UMFPACK/Include/* /usr/local/include/
$sudo install AMD/Include/* /usr/local/include/
$sudo install UMFPACK/Lib/* /usr/local/lib/
$sudo install AMD/Lib/* /usr/local/lib/
$sudo install UFconfig/UFconfig.h /usr/local/include/
- Grab a bleeding edge copy of SciPy and NumPy via their subversion repositories.:
$svn co http://svn.scipy.org/svn/numpy/trunk numpy-from-svn
$svn co http://svn.scipy.org/svn/scipy/trunk scipy-from-svn - Build and install NumPy:
$cd numpy-from-svn
$sudo python setup.py build --fcompiler=gnu95 install - Test NumPy to make sure it's not broken (note that the tests need to be run out of the build directory):
$cd ..
$python -c "import numpy;numpy.test()"
Make sure numpy doesn't fail any of the tests (known fails and skips are okay) or the next bit may not work. - Similar to step 6, build and install SciPy:
$cd scipy-from-svn
$sudo python setup.py config_fc --fcompiler=gfortran install - similar to step 7, move out of the build directory and run the built in tests:
$cd ..
$python -c "import scipy;scipy.test()"
You're going to get some fails and maybe some errors. You're going to have to use your own judgement to as to whether these errors and fails are substantial. Most of the troubles I've encountered are trivial, things like a type being dtype('int32') instead of 'int32' which is actually the same and just needs to be updated to reflect newer numpy.