[9fans] python

["ron minnich" <rminnich@gmail.com>]

I'm at the point of having various tools install better, with a few
simpld additions and bug fixes.

One problem concerns extensions. PYthon loves .so files. Plan 9,
obviously, does not.

Lots of tools are structured in a way that's going to be a real pain
in the ass to fix. Python doesn't do 'make'. what it does is a
standard
python setup.py build
type of thing, and lots of tools 'just know' about /usr/include, etc.
(in spite of the fact that a lot of this junk is parameterized, many
of the tools have it hard-coded). They also know about stuff like .so
extensions, by groveling through (not kidding) the python makefile,
which seems to live in
-rw-r--r-- 1 root root 53592 Oct 23 11:58 /usr/lib/python2.4/config/Makefile

You need a standard set of rules for building a .so, and I am thinking
of something like this:
There is a directory, /pythonext (bind it in or whatever) with
8.out (python)
minimal set of .a? python libraries. from python source
mkfile
base config.c
in it.( config.c establishes the linkage from a python name to a C function. )

the .so ext is (e.g.) a8
building a .so:
build the .a8
cp to (e.g.) /pythonext/pycrypto.a8
echo some line (e.g.) {"pycrypto", pycryptoinit}, >> /python/pycrypto.ext

the mkfile, among other things, gathers the *.ext files into one .c,
then does a standard
mk with all the .a8 files. It's just an extension (ha ha) of what Plan
9 python build does now.

Either that or we finally get around to implementing loadable modules .

ron