[kaffe] Revisiting the class library build system

[Dalibor Topic]

Salut Guilhem,

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.

cheers,
dalibor topic