[kaffe] Re: Revisiting the class library build system

[Jim Pick]

On Thu, 09 Oct 2003 20:06:27 +0200
Dalibor Topic <robilad at kaffe.org> wrote:

> 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.

Sounds cool.

How does this compare to Javamake?

  http://developers.sun.com/dev/coolstuff/javamake/

In another department, it would be nice to have a wrapper for kjc so
that our javac pulled in the extra files in the same manner as Sun's
javac does (with kjc, one has to explicitly list all the files when
compiling, whereas Sun's will automatically recompile dependencies).

If we're completely redoing the build system, I wonder if it might be
possible to rework it so that we could drop the entire classpath tree
into our tree?  eg. Unpack it into libraries/classpath or somewhere
similar.  We could keep our additional classes (eg. VM interface
classes, AWT, Tritonous) in other trees.

Cheers,

 - Jim