Kurt Smith wrote: > Sickness, death in the family, trying to finish my dissertation -- all > cut into my discretionary time. I'll put an fwrap status post on the > blog for those who are interested. > > If you'd like to lend a hand, fparser could use some work. > I thought I'd answer the part about build systems here (see http://fortrancython.wordpress.com/ for original post).
First off, my take is just "do whatever will get any results quickest" and take it from there. As it was said in SciPy 09: The trick is to get things 90% working so that people can start playing with it -- perhaps somebody else will find it easy to step in and create the perfect build solution once they start using fwrap. Get to the point where people can start to scratch their itches. Also be careful that the issue of building Python code and native code together is a problem that's not yet solved -- i.e. there's not yet a standard solution with a significant mindshare. 1. Cython/NumPy distutils: I'd advise against this. David Cournapeau has been the primary maintainer of NumPy distutils, but he's very actively pushing for getting off distutils for scientific use altogether. (And the reason "scientific use" is a category itself is because we have mixed C/Python/Fortran, a land fwrap very much live in.) To start with this David launched "toydist", so that one can use any tool for building and still make Python packages: http://thread.gmane.org/gmane.comp.python.numeric.general/35276 2. Scons or numscons -- those would be my options. Perhaps scons, because presumably numscons users should be able to use scons and numscons plugins? For compiling Cython code there's some work in the Cython repo: Tools/site_scons. In the end, I think it is unavoidable that fwrap will support many build systems, and perhaps that some users want to craft their build systems manually. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
