Bug#256283: [pylucene-dev] Re: PyLucence Debian Package
On Thu, 2 Feb 2006, Jeff Breidenbach wrote:
Hi Matthew,
Good work on the package. However, I don't like that it starts with
Java bytecode
instead of canonical source code. Do you think it would be possible to have the
PyLucene package use the Java Lucene package as a build dependency?
With Lucene 1.9 I moved PyLucene to building from a svn checkout of Lucene
java sources. gcj is much better at compiling .class files than .java files
however, so I use the Java Lucene Ant build and a regular 1.4.2 JDK for the
.java to .class step and release a PyLucene 'source' tarball that includes the
Java Lucene .class files so that Ant and a JDK are not normally required to
build PyLucene unless one wants to build from the very latest sources in the
Java Lucene subversion repository.
Last time I tried to compile Java Lucene from .java source files with gcj I
ended up making 14 patches. There were a number of problems, in particular,
with compiling anonymous inner classes. Experience has shown that compiling
.class files to .o files with gcj is more likely to succeed. Hence, I chose
the path of least resistance since releasing a PyLucene 'source' tarball with
Java Lucene .class files seems to be good enough.
Using the Java Lucene package as a dependency might work once there are no
source patches to Java Lucene anymore. At this time, I still need to apply 4
patches to the Java Lucene .java sources to work around some gcj compilation
or runtime issues before I can feed them to Ant and gcj. Here is the detail on
the patches, in their order of occurrence in PyLucene's patches.lucene file:
- there is a bug in gcj that causes it to produces wrong code when the two
local stack variable named 'required' and 'prohibited' are not initialized.
According to the logic in the java source code, they don't need to be but
their values will swap at some point and lead to errors if they're not.
- gcjh cannot deal with a static method and a static field having the same
name. I filed a bug last year with javacc which is responsible for
generating such unhappy code but no fix has come forward thus far.
- the code relying on a NullPointerException in FieldInfos.java causes the
runtime to crash. Clearly a bug in libgcj or the resulting object code but
the java code is better written to not rely on the exception anyway.
- declaring MAX_BBUF that way worked around another code generation bug
of gcj's for which I don't remember the details at the moment.
These patches were made as needed using gcj 3.4.4
Several other patches were removed after the corresponding changes were made
in the Java Lucene source code (for instance, the workaround for gcj
infamous bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15411).
Andi..
Reply to: