On Thu, 2 Feb 2012, Bill Janssen wrote:
Andi Vajda <[email protected]> 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.
Yes, by replacing it with distutils2, correct ? Not by a configure script.
The only reason setuptools is used is because of this vanilla library
business. Otherwise, plain distutils works just fine.
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.
That could be a question too but not the one I was asking. It seems that JCC
could integrate completely (as a Compiler ?) into distutils/distutil2. But
where is the vanilla shared library build support going to come from then ?
"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.
As far as I know, distutils and setuptools also had the capability to link
with a vanilla shared library. Here, I'm talking about these systems helping
us with building a vanilla shared library that uses Python but that is not a
Python extension.
Andi..
