I notice the build for 2.4.9.3 has been well-fixed with regard to the python extension.
However, I have to question the hardwiring of 2.3 as the python version (requiring me to copy and hack the configure script for legacy pythons).
At present, I'm working to enable building the python extension for legacy pythons going back to 1.5.2.
Why?
Because I'm building a web framework suitable for use on budget public vhosts with poor python support. Many of these budget hosts keep their PHP right up to date, but only have Python 1.5.2.
It's *very* nice to hear that backward compatibility is working out. I hate the game of forcing everyone to hop along the version update game just for the heck of it.
Why is 2.3 hardcoded in configure? Best explanation I can think of is that I always feel completely lost in autoconf, and so I've never dared go in and add more configurability myself. For C++ there is no issue, nor is there for Tcl (because Tcl's stubs make extension binaries built for A work on B>A in just about every case).
If you know how, please do consider fixing unix/configure.in - it keeps coming back, as every new Python release forces me to edit the file again.
-jcw
_____________________________________________ Metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
