[kaffe] Re: Revisiting the class library build system

[Dalibor Topic]

Jim Pick wrote:

> Sounds cool.
> 
> How does this compare to Javamake?
> 
>   http://developers.sun.com/dev/coolstuff/javamake/

JavaMake has some license I've never heard of, that's not on their site 
(BSD+). JavaDeps is GPL.

JavaMake uses a project database, which sounds awfully like some binary 
file, and I wouldn't want another in the CVS, Klasses.jar.bootstrap is 
bad enough. ;) Beside that, it doesn't seem to be able to export 
dependencies in the 'make' format, which makes it useless for the 
insteresting case: you're on a slow, interpreter only machine, debugging 
kaffe, and don't have time to waste rebuilding the class library with a 
java tool.

Whereas the dependencies generated by JavaDeps seem to be perfect for 
inclusion into a Makefile.

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

Sun's automatical recompilation of dependencies has some seriously bad 
reputation on the jikes mailing list, at least. See also 
http://www.cs.mcgill.ca/~stever/software/JavaDeps/ which lists broken 
dependency tracking by Sun's javac as one of the reasons to make JavaDeps.

While such a wrapper may be nice, I don't think it would be necessarily 
easy to get right. ;) On the other hand, that's probably an issue for 
the kcj development lists, as their developers may already have 
something like that, but we just haven't found it yet ;)

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

Tricky. If we drop the entire classpath tree into kaffe's CVS, a lot of 
it will be useless for kaffe: the swing stuff won't build on kaffe, I've 
tried that. I'd prefer a slow and careful migration, that allows for 
easier isolation of bugs in Classpath.

I don't mind pulling the other stuff apart, though. But I don't see 
anything gained by doing that, except from a more clearer overview where 
what came from originally. ;)

cheers,
dalibor topic