[kaffe] Dealing with class library dependencies and simplifying the class
library build system once more
Dalibor Topic
robilad at kaffe.org
Fri Jun 18 21:39:02 PDT 2004
Hi all,
one thing that pops up every now and then, in particular if one is stuck
on a not very fast CPU, is the question if it would be possible to have
the java class library build take care of the class file dependencies
and just recompile the dependant files.
I took a look at that issue a few months ago [1] with JavaDeps. It
wasn't superbly suitable for what we'd need to do, and had some flaws
that made it unuseable for dependency calculation of the core class
library. I wanted to re-investigate jikes eventually, and I don't quite
like what've seen there either.
Jikes has several dependency information generation output mechanisms.
One of them is to make jikes output into a file, but that information is
unparseable for make, as far as I can see it. The other is to let jikes
write dependency infomation for each class into its own '.u' file. That
one is actually quite cool, but generates about 130 megabytes of
dependency information for kaffe's class library [2]. Chances are that
parsing those 130 megs of dependency information will take make longer
then simply recompiling everything from scratch with any compiler, in
particular with jikes. And there is no way we'd put 130 megs of mostly
unused dependency information into CVS anyway, so the idea to use jikes
to create dependency information is dead.
So I turned to JavaDeps. Lucent updated their implementation to version
1.2 in april, and this one no longer has the problems the provious one
had with our source code. It's still 5 megabytes of in most cases
unuseful information in the CVS, and would essentially need to be
updated on every check in, leading to the same problems with broken
builds due to missing classes that we have now with the
essential.files+profiles setup, so I'd rather not use it either.
Instead, I'd like to propose to do the simplest thing: compile all files
at once, without any difference between essential and non-essential
files. Instead of the current profile support that works via
directories, I propose to allow the configure script to receive an
absolute path to a file that contains a list of all files to be compiler.
This would solve the rather ugly problem of having to keep in sync our
current build system, as generating the list of java files comes down to
a 'find gnu kaffe java javax org -name "*.java"' and thus could be
done automatically [3].
It would also increase the amount of memory needed to build the class
library as all files would have to be compiled in a single pass. I can't
say by how much, I'd expect that the requirement would double to around
100 megabytes using jikes, and probably somewhat more than that using kjc
I'd also eventually like to make jikes the default compiler for the
class library build, since it is more likely to get us through a
bootstrap than kjc on platforms where the ports have suffered from
bitrot. Using kjc as a default for bootstrap makes it quite hard for the
ocassional developer on odd platforms to try to fix regression test
failures, when he doesn't get past the class library build stage.
I'm trying to resolve some problems with some failing regression tests
with jikes first, though. [4]
cheers,
dalibor topic
[1] http://www.kaffe.org/pipermail/kaffe/2003-October/044289.html
[2] It is quite good depenency information, really. It lists both
Object.class and Object.java everywhere and does similar neat tricks
that JavaDeps doesn't. On the other hand, dependency information from
JavaDeps is much better condensed, so you have a few megavytes vs. more
than hundred. :(
[3] except for the win32 awt files, but AWT will be moved away to its
own subdirectory to make space for Classpath's AWT and Swing soon, and
that problem will thus be solved, too
[4] This is all part of the preparation of the big AWT/Swing merge from
GNU Classpath :)
More information about the kaffe
mailing list