On Tue, 18 May 2010, Christian Heimes wrote:
Setup
=====
I'm running the tests on an Ubuntu 10.04 X86_64 box with Python 2.6.5, Sun
Java 1.6.0_20, GCC 4.4.3 and patched setuptools 0.6c11 (all 64bit).
JCC:
$ svn co
http://svn.apache.org/repos/asf/lucene/pylucene/branches/branch_3x/jcc jcc_3x
$ cd jcc_3x
$ JCC_JDK=/usr/lib/jvm/java-6-sun python2.6 setup.py build
$ JCC_JDK=/usr/lib/jvm/java-6-sun python2.6 setup.py install
Small issue: The install target always rewrites the jcc.config module. This
is a problem when I install JCC with "sudo python2.6 setup.py install" since
it's not trivial to keep the environment variable JCC_JDK across a sudo call.
How do you like the idea to bind the creation of jcc.config to the build or
build_ext target?
That makes sense. Consider it a bug that it doesn't.
LUCENE:
$ cd ../pylucene-2.9.2-1
$ make ANT=ant PYTHON=python2.6 JCC="python2.6 -m jcc.__main__ --shared"
NUM_FILES=2
$ make ANT=ant PYTHON=python2.6 JCC="python2.6 -m jcc.__main__ --shared"
NUM_FILES=2 install
Suggestion: How about providing sensible defaults for ANT, PYTHON, NUM_FILES
and JCC? It's annoying that I have to type the arguments over and over again.
;)
The Makefile has about a dozen sets of defaults for a variety of platforms.
Pick the one closest to your setup, uncomment it (and change it if needed).
Then you don't have to enter these on the command line.
Issues
======
- I have to follow a strict order (first import lucene, than
lucene.initVM(export=True), finally import bobobrowse). When I try to import
bobobrowse before the call to initVM(export=True), the import fails with
unresolved symbols. Have you tried to add _lucene.so as a dependency to
_bobobrowse.so? I believe a dependency should make the dlopen() call
obsolete.
This is how I solved this on Windows. I'll try to see if the same trick
works on Linux. If it does, then the export=True parameter would become
unnecessary. Still, unless the dynamic loader can find _lucene.so on its own
(and it should be via some -rpath tricks), loading the --import'ed module
first might still be a good idea.
- With "--import lucene" JCC gets the class_ attribute of all types wrong,
that are part of the bobobrowse package. It either shows java.lang.Object as
class_ or the first lucene class in the hierarchy. Without "--import lucene"
it works as expected.
I don't have this problem with my simple program.
My SillyAnalyzer class extends Lucene's Analyzer.
foo.Analyzer is the one imported from lucene.
>>> import lucene, foo
>>> lucene.initVM()
<jcc.JCCEnv object at 0x1004100d8>
>>> foo.initVM(".")
<jcc.JCCEnv object at 0x100410180>
>>> foo.SillyAnalyzer.helloWorld()
Hello World
>>> foo.SillyAnalyzer.class_
<Class: class bar.SillyAnalyzer>
>>> foo.Analyzer.class_
<Class: class org.apache.lucene.analysis.Analyzer>
I'd very much like to try to reproduce your problems with your software.
Is there any way I can get your stuff and build it here ?
It would be much easier to debug this if we worked with the same stuff.
- I've run into a rather strange bug with our custom builds of Python 2.6. It
differs from the stock build of Ubuntu in two ways. The python2.6 binary is
linked against libpython2.6.so (Ubuntu's python2.6 binary has libpython2.6.a
statically linked in) and I've set the environment variable LD_RUN_PATH which
causes the linker to add a "library rpath" to all ELF binaries. I wasn't able
to find the reason for the issue so far. Any hints are appreciated.
You didn't describe the "rather strange bug" or am I missing something ?
Andi..
