Andi Vajda <va...@apache.org> wrote: > > I think the right thing to do is to > > > > 1. re-write the current jcc setup.py to use distutils2, and then > > Is distutils2 supported on older Python 2.x versions like 2.4, 2.5 ? > I'd be happy to drop support for older releases for sure. We currently go all > the way back to 2.3.5.
At https://bitbucket.org/tarek/distutils2/wiki/Home, it says, ``distutils2 will be distributed as a third party module compatible with Python 2.4-3.2 under the name “distutils2"''. So, yes. > > 2. at the PyLucene level, add a configure.ac script which figures out > > the proper settings for those six or so defines in the Makefile, > > which is a fairly trivial configure script. > > If I understand this correctly, your configure script does not take > care of the libjcc.so build part, the 'cause' of the setuptools > patching mess. That's correct. It just figures out the environment variables and parameters to set so that setuptools will work properly. The right thing to do is to eliminate setuptools. > Unless distutils2 handles building vanilla shared > libraries (as opposed to python extension shared libraries), we'd > still be stuck with that problem. The question for JCC is whether to abandon setup.py (and do everything with autotools and configure), or to move setup.py onto a newer and probably better platform (distutils2 instead of setuptools). Or, I suppose, some combo of the two. "configure" would provide better support for building shared libraries, but less understanding of and support for Python specifics, like building extensions. Moving to distutils2 instead would probably be less work. I see that distutils2 has functions like "link_shared_lib", and "link_shared_object", which is a good sign. Whether they work or not is another matter. Bill
