On Thu, 13 May 2010, Andi Vajda wrote:
On Fri, 14 May 2010, Christian Heimes wrote:
Thanks for the suggestion, Andi! I'll try your suggestion on Monday. I hope
it's sufficient to create a working version of lucene + bobo-browse in
order to provide my co-worker Julian a foundation for his work on
bobo-browse. But I fear that it's not going to work. I carefully excluded
any jar file from the bobobrowse egg that is already part of pylucene
(--classpath instead of --include or --jar). The lucene class are probably
wrapped because bobo-browse references the classes in its jar file.
By the way I've created the Makefile for bobo-browse based on your Makefile
for pylucene. With your template and your good work it was trivial to
create the Python bindings. Thanks ;)
I've an idea how you can solve the inter-package issue. Is it possible to
create some kind of type interference for JCC types that point to the same
Java class (e.g. lucene.Query.class_ == bobobrowse.Query.class_)?
Ah, I see now the bigger problem. What you're really after in the case where
bobo would cause its own lucene wrappers to be generated is the ability to
import them from the lucene extension instead. For this, the symbols would
need to be exported and the C++ headers generated by jcc during the pylucene
build included in the lucene egg. I think this could be done. Give me a few
days to think about this... say via a new --import jcc commmand line option.
I added support for a new jcc command line option called --import which
accepts the name of another jcc-built extension such as 'lucene'.
This is checked into the new branch_3x pylucene branch [1] which mirrors the
new lucene branch_3x branch that reflects the recent changes in the lucene
svn tree with regards to backwards compatibility changes.
The new JCC in that branch now installs all header files it generates for a
--shared extension into the extension's egg under an 'include' directory.
Therefore you must rebuild pylucene with this latest JCC first to try this
out.
When an extension is imported via jcc's --import command line flag, its
header files are scanned so that the importing extension reuses the code
from the imported extension instead of generating wrappers for these classes
again.
This works quite well on Mac OS X where the dynamic linker finds the
code objects (methods) for the imported classes for the imported extension
at runtime without any problems provided the jcc-imported extensions are
imported into python first.
On Linux, there's got to be a way to make this work but I haven't found how
yet. I seem to be having trouble with linking to the Python Type objects. On
Windows, I expect this to be even more difficult.
I don't know what operating system you're on. If you're on Mac OS X, please
try this out and let me know if it solves your problem. I intend to work on
the required Linux linker tricks next.
I created a simple test case that extends Lucene's Analyzer class but in
another extension that is built by thus importing lucene. The command line
to build it looks like this:
python -m jcc.__main__ --classpath `pwd` --python foo --import lucene
bar.SillyAnalyzer --shared --build --install
Andi..
[1] http://svn.apache.org/repos/asf/lucene/pylucene/branches/branch_3x/
