Andi Vajda wrote:
On Mon, 10 Jul 2006, Doug Cutting wrote:
Andi Vajda wrote:
On Sat, 8 Jul 2006, Doug Cutting wrote:
Since GCJ is effectively available on all platforms, we could say
that we will start accepting 1.5 features when a GCJ release
supports those features. Does that seem reasonable?
+1
If we use this criteria, then we should probably officially support
GCJ. Ideally we should run nightly unit tests with GCJ. Andi, would
you be interested in helping to set this up?
This is interesting to me, is the nightly build environment difficult to
replicate ?
I'd be interested in doing this but what is it that we're after in
'supporting gcj' actually ?
There is some advantage in using gcj as a measure of usability in the
context of a "free (as in beer)" java, such that for a given target
platform, one can deliver executables and shared libraries without
requiring virtual machine runtimes. The second advantage is to give a
simple method to nightly test contributions using new features. The
third advantage seems to be a reduction in computational load on servers
running native code.
- running a fully compiled program linked against a lucene.so ?
if so, which platforms ? the gcj story is very different on each and
every
platform, including different linuxes and gcj is not well supported on
some platforms at all.
This seems to be the case, since on an updated fedora core 5 with gcj
(GCC) 4.1.1 20060525 (Red Hat 4.1.1-1), the Makefile modifications
required are trivial.
- running java bytecode with the gcj VM (gij, I believe) ?
if the .java code needs to be compiled with gcj then a number of patches
still need to be applied against the Java lucene sources.
PyLucene is built by compiling .java -> .jar using a regular JDK (Apple's
or Blackdown) and using gcj to compile from .jar -> .so thereby working
around all the gcj java front-end bugs
Even when only compiling .jar -> .so with gcj, a number of patches still
need to be applied:
http://svn.osafoundation.org/pylucene/trunk/patches.lucene
The last time I checked for src/gcj/Makefile (revision 420696), all that
was required was to fix the name of the lucene archive file to match
what is actually generated, e.g., $(BUILD)/lucene-core-[0-9].*.jar and
add the FieldCache* to the names to skip . . .
Not having contributed to lucene yet, is it required to generate a
'patch' to add to jira, or is the following output from a simple `svn
diff` sufficient for experimentation ?
Index: src/gcj/Makefile
===================================================================
--- src/gcj/Makefile (revision 420696)
+++ src/gcj/Makefile (working copy)
@@ -8,7 +8,7 @@
CORE=$(BUILD)/classes/java
SRC=.
-CORE_OBJ:=$(subst .jar,.a,$(wildcard $(BUILD)/lucene-[0-9]*.jar))
+CORE_OBJ:=$(subst .jar,.a,$(wildcard $(BUILD)/lucene-core-[0-9]*.jar))
CORE_JAVA:=$(shell find $(ROOT)/src/java -name '*.java')
CORE_HEADERS=\
@@ -55,7 +55,7 @@
# yet accept from .class files.
# NOTE: Change when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15501 is fixed.
$(CORE_OBJ) : $(CORE_JAVA)
- $(GCJ) $(GCJFLAGS) -c -I $(CORE) -o $@ `find $(ROOT)/src/java
-name '*.java' -not -name '*Sort*' -not -name 'Span*'` `find $(CORE)
-name '*.class' -name '*Sort*' -or -name 'Span*'`
+ $(GCJ) $(GCJFLAGS) -c -I $(CORE) -o $@ `find $(ROOT)/src/java
-name '*.java' -not -name '*Sort*' -not -name 'Span*' -not -name
'FieldCache*'` `find $(CORE) -name '*.class' -name '*Sort*' -or
-name 'Span*' -or -name 'FieldCache*'`
# generate object code from jar files using gcj
%.a : %.jar
more,
l8r,
v
--
"The future is here. It's just not evenly distributed yet."
-- William Gibson, quoted by Whitfield Diffie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
