On Wed, 20 Feb 2008, Bill Janssen wrote:
The untested (there is a lunar eclipse going on) patch below should solve
the problem.
I'll catch the Flickr photoset later :-).
I actually tried that fix earlier, and no dice. The classes are
generated, but array.h still gets pulled in. Haven't figured out why,
yet.
Shouldn't the generated #includes be to <file.h> instead of "file.h"?
You're always generating the path relative to the compiler's set of
include directories, not relative to the current directory.
I thought that <file.h> was for system headers and "file.h" was for 'my'
headers. I could be wrong...
Later: ah, it's String. The functions.h file in JCC references
"java/lang/String.h", so you always need to generate that, too.
Adding that makes things work.
Yep, that makes sense.
All the bugs you found today are the so-called second use bugs. So far, no
one that I know of (including myself) has tried JCC with anything but
Lucene. These missing headers are there when Lucene is wrapped since they
get pulled in by Lucene classes.
The field accessor bug you found reflects the lack of public fields in
Lucene.
Andi..
_______________________________________________
pylucene-dev mailing list
[email protected]
http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
