[kaffe] Rewriting class library compilation

[Dalibor Topic]

Hi,

before I go and rewrite class library compilation a
little bit, I'd like to hear if anyone has attempted
to fix the remaining issues with class library
compilation.

Here's a short list of things I don't like with the
current way of things:

1. It is inconvenient.

When I add new classes to the lot, I have to touch
Makefile.am, regenerate Makefile.in, recompile all of
kaffe again before I can see if the new classes break
when compiled under kaffe with kjc. Using jikes helps
a little, but not much.

2. It is broken.

At least under IRIX, it's not possible to compile
kaffe anymore because the maximum command line length
is exceeded. Since the makefile passes all class names
that need to be compiled to rebuildLib, the command
line can be quite large, actually.

3. It is not flexible.

There is no easy way to specify a different mix of
classes for rt.jar. Sure, one could hack away at
Makefile.am, and go though the
recompile-everything/hack Makefile.am a couple of
times until it stabilizes. But that's not exactly what
I'd call flexible. Kaffe should have an easier way of
tailoring rt.jar to one's needs. Embedded developers
may not need all the great stuff in the class library.
The currently official way of stripping down rt.jar is
to remove the classes from it after the compilation,
according to FAQ.embedded. That approach can cause
trouble if you cut away classes which are used to
implement others. It would be better if the users
could specify what classes they want in their rt.jar
in some less tedious way. They would be greeted by
friendly compile time errors instead of
ClassNotFoundExceptions at runtime ;)

So here's my proposal:

I'd like to introduce two new kinds of configuration
files into libraries/javalib. We already have
bootstrap.classes and I'd like to add similar files
for compilation passes and classes to be compiled in a
run.

* New configuration file: configuration-name.profile

Syntax like boostrap.classes. A list of passes that
the compiler is supposed to make in order to compile
the class library. Each pass is actually a file name.

* New configuration files: some-pass-name.files

Just a plain list of files. It would contain all the
files that need to be compiled together in a single
pass.

* Makefile.am would be reduced to doing little
processing of the *.profile file. It would call
rebuildLib with each *.files file from the *.passes
file until it's done.

* rebuildLib.in would just pass the *.files file name
to the compiler as the @files parameter. I think every
java compiler accepts this option. Jikes, javac & kjc
do, and I think gcj does as well.

How does this solve the issues mentioned above?

1. Adding new classes becomes just a matter of adding
them into a *.files file. In a case of adding a wholly
new set of classes, one could also edit the respective
*.profile file to include a new *.files file, and put
the classes in the new *.files file. 

No need to reconfigure or recompile anything.

2. Compiling on platforms with short maximum line
length is no longer an issue, as the only thing that
gets passed to rebuildLib is a single file name.
RebuildLib also only passes a single file name
parameter to the compiler.

3. Flexibilty comes into play. Suddendly, if you have
a lot of RAM to work with, you can compile kaffe's
class library in a single pass. If you have little
RAM, and need to split it into more passes, you can.
If you need to cut it down to only the classes you
need for your app, you can. If someone contributes
'class library profiles' for JDK 1.0, 1.1, 1.2, j2ME
etc, you can reduce kaffe's class library to the
extent of that platform [1].

If we get some configurations contributed, I'd like to
have a --with-class-library-profile=profile [default,
single-pass, minimal-ram, hello-world, ...]
configuration time option to pick a profile.

Before I go off and implement this, I'd like to hear
your opinions.

best regards,
dalibor topic

[1] In a limited sense, as you'd still have parts of
classes included that don't 'belong' into that
release. How to handle such a 'jdk-x.y profile' has
been the subject of some discussion between jukka
santala and me, but no really good solution
materialized. Search kaffe's mailing list archives
using mail-archive.com if you want to know more.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com