On 11/29/07, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Barry Wark wrote:
Using the gfortran from http://r.research.att.com/tools/, it's trivial to build a universal build from source. The instructions on scipy.org won't lead you astray.
I will ask around at work. Perhaps we can start building universal scipy builds for distribution. Can anyone from the scipy devs email me off list if you'd like to pursue this?... triggering a build automatically from SVN commits or such would be good. That would be cool, but where to compile the binary ? scipy does not have build farm. Having a 100 % automatic way to build a binary would certainly be a step in this direction, though. There is also the need to test the compiled binary, which is not trivial with fat binaries. To sum up: - we need at least one x86 mac os X machine to build/test (I don't know if you can test python softwares through rosetta: I have only experience testing pure C softwares built as fat binaries)
One of our machines (OSX Intel) is already the buildbot slave for the numpy buildbot. I think I can get us OK'd to build scipy on there as well. We generate our own scipy builds so it shouldn't be too big a problem. Unless there's an automated system, I'd prefer to to just release builds. Some remaining issues: - which SDK to build against. Leopard ships with a Python build against the 10.5 SDK. It would be much easier, at least initially, for us to produce binaries against the Leopard Python 2.5. - how to deal with library dependencies such as fftw2. We currently use MacPorts but I suppose it needs to be compiled statically or do we just require that users install MacPort's fftw2?
- we need a way to automate the build entirely
It seems like scipy needs a buildbot.
- we need a way to automate the packaging (distutils can do only part of it or all of it ? Building a basic .pkg inside a dmg is not hard from the command line, but I don't know how it scales for non trivial packages).
It's relatively easy to build a single pkg for the entire scipy distribution (that's what we do now) and put that on a DMG (as you said). When scipy becomes a less monolithic package (i.e. using setuptools namespace packages), we can create a pkg for each package and a mpkg combining them all. ~barry