[kaffe] Revisiting the class library build system
Thu Oct 30 05:04:02 2003
Guilhem Lavaux wrote:
> Dalibor Topic wrote:
>> 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. ;)
> I am personnally totally for that sort of revisiting. These dependency
> fixes are quite annoying and time consuming. If we had a way to make it
> fully automatic introducing new classes in the CVS would be really easy.
> This only leaves for me 2 drawbacks:
> * presence of quite a big file in the CVS
> * and maybe the time for GNU make to parse and check the dependency tree
> when building.
> But personally the advantages are so important that I would just forget
> these two.
O.K., I went ahead and fought a battle with JavaDeps a day and a night.
Here are my findings:
JavaDeps (the latest Lucent release) is still quite buggy. Running it on
essential.files from libraries/javalib produces garbage binary
characters in the output. The only way to make them go away is to turn
the comments off, i.e. run JavaDeps --silent .
It creates incomplete dependency trees: all java classes should depend
on java/lang/Object.class, but they don't. The output dependency tree
seems to have several roots, which apparently leads make to start
building some Exception classes first, before building java.lang.Object.
This approach fails on kjc.
On the pro side, it seems to work: once the class files are compiled,
changes to a class trigger only incremental compilation steps until all
dependant classes have been recompiled.
Coming back to the con side, it takes an enormous amount of memory to
process the dependency list (ca 6M on disk): GNU make needs 74M to
process the whole list.
The presence of the big file in CVS is not as bad in my opinion, as the
points noted above, especially the ludicrious memory consumption by GNU
make. If we can fix that, and fix JavaDeps to really have a single root
in the object space, it could be worth it.
One of the things that could help may be extending JavaDeps to support a
recursive make: that way only the dependencies within a
subdirectory/package may need to be stored in their package dirs, and
only the cross-package dependencies would have to be stored somewhere
else. Unfortunately, JavaDeps as it is (lucent or not) seems largely
unsupported, so we'd basically have to fork it. Ugh.
I'm looking forward to your comments.