[kaffe] Revisiting the class library build system

Dalibor Topic robilad@kaffe.org
Thu Oct 9 11:11:02 2003


Hi all,

with 1.1.2 out of the door, I think it's the appropriate time to revisit 
our class library build system once more. ;)

While the current build system works all right in most cases, it doesn;t 
fully utilize make's dependency checking. So if you change a java class 
source file to fix a bug, you need to recompile the whole class library. 
That's quite expensive when all you've got to build java classes is kjc, 
and you're running on the interpreter engine. Especially if you decide 
to interrupt your build in the middle of the class library compilation. ;)

So I've looked around a little bit to find ways to generate the 
dependency information from class libraries for the makefile. There are 
two solutions I know: jikes, and JavaDeps.

jikes has a +M option that can generate Makefile dependencies. The 
generated file looks very binary to me, and doesn;t seem to be suitable 
for inclusion into a makefile. I'd also like to avoid having more binary 
files in the CVS than necessary. The +DR option doesn't generate 
dependencies in a way that make understands either, from what I've seen.

JavaDeps seems like the right thing. Especially the version extended and 
maintained by lucent loks quite nice. It's available here: 
http://www.bell-labs.com/project/nmake/release/jdeps.html

I've put up the javadeps generated dependencies for kaffe's class 
library (with native java.math) up here: 
http://www.kaffe.org/~robilad/libfiles-jdeps.bz2

It's about 5 megs unpacked, which is quite big, for a file to put into 
CVS that doesn't add that much functionality.

On the other hand, the pros may outweigh the 5MB con: instead of having 
to manually update essential.files whenever something crucial changes, 
we could just have the rule to

rt.jar: Makefile.classlib
	make -f Makefile.classlib java/lang/Object.class
	$(PROFILE_BUILD_SCRIPT)

instead.

We'd still need to regenerate the dependencies when necessary (as a part 
of autogen.sh, for example).

The profile support would also be vastly simplifyed: instead of manually 
listing files in batches to build, and trying to get the dependencies 
right, you'd just need to write a wrapper to call the Makefile.classlib 
with the list of classes you need to have built, and the dependencies 
would automatically be resolved by make. So you could grep for the 
classes imported by your embedded application, and quite easily generate 
a class library profile based on that.

as usual, I'm interested in your comments, before I start hacking on it.

cheers,
dalibor topic