Merging in Classpath and PocketLinux AWT (Was Re: [kaffe] CVS kaffe (dalibor): Implemented -Xbooclasspath options)

[Dalibor Topic]

Kaffe CVS wrote:
> PatchSet 4755 
> Date: 2004/05/20 13:51:38
> Author: dalibor
> Branch: HEAD
> Tag: (none) 
> Log:
> Implemented -Xbooclasspath options
> 
> 2004-05-20  Dalibor Topic  <robilad at kaffe.org>
> 
>         * kaffe/kaffe/main.c:
>         (options) Added -Xbootclasspath and Xbootclasspath/a
>         option handling.
>         (usage) Added new options. Fixed intendation problems.
> 
>         Reported by: Julio M. Merino Vidal <jmmv at menta.net>

-Xbooclasspath/p was actually implement for quite a while, just not 
really documented. I think a few people asked for this.

In the interesting short run, this should enable us to proceed with 
merging in Kaffe's Pocketlinux AWT implementations and GNU Classpath's 
AWT implementations side by side without having to do a lot of 
retrofitting of kaffe's peerless implementation first. I'm looking at 
Jim Huang's work to see what he did to get classpath's AWT running on Kaffe.

This should make the implementation of the ideas [1] for further AWT 
merges quite straight forward. The goal is to have the AWT 
implementation selectable at compile and/or runtime. Here's my plan:

1) move AWT files in current libraries/javalib into their own 
subdirectory, like libraries/javalib/awt-implementations/kaffe/.

2) Build it separately from the rest of class library as kaffe-awt.jar.

3) make sure it gets picked up on the bootclasspath by default.

4) merge in Classpath's AWT and Swing into the libraries/javalib as the 
'normal' AWT. The reason for that is that Classpath implements more 
up-to-date AWT APIs than Kaffe's AWT does. By making Classpath's AWT the 
'default' API, we can allow more programs to be built against kaffe. 
That doesn't necessarily mean that Classpath's AWT becomes the 'default' 
AWT right now. But it means that we can follow GNU Classpath's rapid 
developement in this area, and have very nice things like the portable 
AWT-over-frambuffers implementation from Odonata[2] running on kaffe.

5) Add an option to pick up the desired AWT on the command line. 
-with-awt=kaffe would let you run kaffe's AWT, --with-awt=classpath 
would let you run classpath's AWT.

6) Merge in Pocketlinux AWT in its own directory. (Merge in Rudolph. 
Merge in DirectFB AWT. Or any other GPL-comaptible AWT toolkit ;)

7) Add pocketlinux option.

8) Eventualy, add a --with-awt-backend option to kaffe binary to pick 
the native AWT backend for Kaffe and Pocketlinux AWT implementations.

That's my plan for the next couple of days. If Jim Pick agrees, we may 
be able to put it in into 1.1.5, even, if it turns out to work well.

There is one draw-back: if you're using Kaffe's AWT in an embedded 
system, you'll have to work around Classpath's AWT being compiled in by 
default. You should be able to do that by removing the awt.files file 
from the default profile, though, or by defining your own class libray 
profile withuot AWT and adding the separate kaffe-awt.jar.

cheers,
dalibor topic

[1] http://www.kaffe.org/pipermail/kaffe/2003-June/042719.html
[2] http://odonata.tangency.co.uk/