This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Kawa Compilation
Nigel Dolby wrote:
What is the significance of the fact that the current CVS archives has
fixed the problem I described in my last e-mail, and what might I do
about that? Is there a new Kawa binary I could download, and where? Or
would I have to build a new Kawa for myself?
The latter.
If I have to build it, I
could do that - rather slowly - under Linux, given precise enough
instructions (Xandros provides command prompt access through bash).
You can also build it on Windows using ant. However, I don't test
ant builds as frequently, so they sometimes break, and they don't
provide as much control over build options etc.
But you can try the ant build. If it's broken, I'll try to fix it quickly!
Once
built, Kawa appears to port directly from Linux to Windows. When I read
the instructions on "Installing and using the source distribution" in
the Kawa documentation all sorts of questions come to mind. "In your
build directory": I don't currently have a build directory (for
anything); what is a good choice for this - some subdirectory under my
home directory? - or must it be a system-level directory?
No - any writable directory is fine. It can be the same directory as you
unpack the sources into, or some new initially-empty directory.
(I am the only
user of my systems.) What is $PREFIX and how does it get set?
It defaults to /usr/local. If you're building a "system package" you'd
set it to /usr. It's wherever you want "make install" to install
the files into.
In your case, you don't need to do a "make install" (you'll manually
copy over the .jar file to your Windows box), so it doesn't matter.
Do I need
the --enable-kawa-frontend flag if I want to mark, copy and paste in the
Kawa window (I do)?
No. The --enable-kawa-frontend is to build a front-end that uses readline
command editing (as also used by bash). It has nothing to do with a
separate Kawa window. --enable-kawa-frontend will probably not work
on Windows, at least not without special libraries like CygWin.
Do I need --with-swing if I intend to use Swing even
without JEmacs (again, I do)?
It doesn't hurt - and I think it's the default. But --without-swing
doesn't prevent using Swing - it just means Kawa itself won't use
Swing, or build any components that depend on Swing.
If all the needed details are already
explicitly documented, perhaps you could point me to the appropriate
location, otherwise, if it is necessary to do a build, a good approach
might be if you were to publish or send me exactly the setup and
commands used to build the distributed binary version of Kawa, since
this provides functionality adequate for what I am currently doing.
I don't know what you mean by "the distributed binary version of Kawa".
If you build Kawa on Xandros Linux, then you can just copy over the
resulting kawa-XXXX.jar file to Windows and you should be ok.
On a different but related subject, I decided I could explore some
interface questions directly in Kawa, without needing to use an Applet,
and I entered and ran the code below (adapted from The Definitive Guide
to Java Swing by John Zukowski - ISBN 1-59059-447-9 - pp. 19-22). The
code just creates a new window with a button that causes printing in the
Kawa window when pressed, but it does it on a new thread. The code runs
fine (once you discover that the method signature includes the return
value type, which is not true in Common Lisp), but when I close the
window it creates on its new thread, Kawa closes too. If you run the
code on the Kawa thread that also happens, which is fair enough, but I
think I would have expected the Kawa window to remain open in the
separate thread case.
Huh? Isn't this what you asked for when you set EXIT_ON_CLOSE?
For JDK 1.4.x I had to add an explicit getContentPane:
(invoke (invoke frame 'getContentPane)
'add button (static-field <java.awt.BorderLayout> 'SOUTH))
or more compactly using the colon notation:
((frame:getContentPane):add button <java.awt.BorderLayout>:SOUTH)
As a matter of style, I now prefer a :: before the return type:
(define-simple-class <AnActionListener> (<java.awt.event.ActionListener>)
((actionPerformed (actionEvent :: <java.awt.event.ActionEvent>)) :: <void>
(format #t "~%I was selected~!")))
You might want to try out:
http://www.gnu.org/software/kawa/gui/graphics.html
I'm currently concentrating on shoving Qexo though the XQuery testsuite,
but after that I will concentrate on the GUI support for server-side
applications. I have code that sort-of works but has some bugs and needs
to be cleaned up before I check it in.
Once that is done, then it's time to think about Kawa 1.8.1.
--
--Per Bothner
per@bothner.com http://per.bothner.com/