From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <13426df10701041431w2272898eu3b620dd2b33086ff@mail.gmail.com> Date: Thu, 4 Jan 2007 15:31:23 -0700 From: "ron minnich" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [9fans] python Topicbox-Message-UUID: fcfa64d8-ead1-11e9-9d60-3106f5b1d025 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