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 :)
_______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
