This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
GCJ PPC Success and DOM
Hi Gang.
I've finally got a GCJ to work on PPC.
The GCJ (3.3.3) in Yellow Dog Linux 4.0.1 works fine (hopefully I'll be
able to figure out how to build 4.0 from that). No joy yet for OS X,
but it also occurs to me I should ask the Apple folks to include GCJ in
OS X Tiger (or at least patch up their GCC branch to work).
Two things I had do:
Turned out easiest way to get W3C DOM compiled was to add it to Kawa's
build (along with an --enable-w3cdom switch). Not sure if you want to
add it to Kawa too, but I'ld be happy to send you the patch if you like.
And what should we do about DOM Level 2 vs Level 3? Should Kawa
preprocess itself appropriately to support both?
In any case I got a decent handle on how the GCJ native build stuff
works now. I'm planning on looking into a unified build using Ant
and/or Kawa now to eliminate the double maintenance (perhaps by
generating the Makefile.am files).
Other thing I had to do was because I built --without-awt (YDL gtk is
wrong version apparently) I got an exception in (compile "PrimOps.scm")
because Scheme.getInstance() fails, so my workaround is:
Index: Scheme.java
===================================================================
RCS file: /cvs/kawa/kawa/kawa/standard/Scheme.java,v
retrieving revision 1.178
diff -u -r1.178 Scheme.java
--- Scheme.java 7 Mar 2005 08:03:38 -0000 1.178
+++ Scheme.java 23 Mar 2005 00:25:24 -0000
@@ -7,6 +7,7 @@
import gnu.expr.*;
import java.util.Hashtable;
import gnu.text.SourceMessages;
+import gnu.kawa.lispexpr.LispLanguage;
import gnu.kawa.lispexpr.*;
import gnu.lists.FormatToConsumer;
import gnu.kawa.functions.DisplayFormat;
@@ -531,7 +532,17 @@
define_proc ("load-compiled", "kawa.lang.loadcompiled");
defProcStFld("environment-bound?", "kawa.lib.misc");
defProcStFld("scheme-implementation-version", "kawa.lib.misc");
- defProcStFld("scheme-window", "kawa.lib.windows");
+
+ try {
+ // Skip this symbol if the class is undefined.
+ // If we leave it in then Language.getInstance blows up.
+ Class.forName("kawa.lib.windows");
+ defProcStFld("scheme-window", "kawa.lib.windows");
+ } catch (final ClassNotFoundException e) {
+ // Must not be configured for AWT.
+ }
+
+
defSntxStFld("define-procedure", "kawa.lib.syntax");
defProcStFld("add-procedure-properties", "kawa.lib.syntax");
defProcStFld("make-procedure",
Is this the right thing or should there be a more general solution for
symbols that fail (which happens later when importLocation is done in
CommonLisp).
Jim