[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