[kaffe] Dealing with class library dependencies and simplifying the class library build system once more

[Dalibor Topic]

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 :)