[kaffe] Projects/sub-projects dependancies... Thoughts

[Dalibor Topic]

Hallo Michael,

Michael Franz wrote:
> Hi,
> 
> I have been looking at Kaffe-1.0.7 (the last version that works on Mac 
> OS X) to figure out some of the threading issues that I think are 
> breaking kaffe on OS X.  In my attempt to put together some test using 
> thread.c, I have found that there are a circular dependancies between 
> the sub-projects and each project can not be easily built outside of the 
> existing makefiles.  At least for me.  I have listed (below) what I have 
> found, the latest HEAD version seems to have more dependancies.
> 
> include
> - depends on config
> - depends on kaffeh
> - depends on Klasses.jar (used by kaffeh to build all the java* headers)
> kaffe/kaffeh
> - depends on include
> - depends on kaffe/kaffevm (shares numerous header and C files)
> - depends on config
> - HEAD depends on the threading subsystem to compile (jthreads vs pthreads)
> kaffe/kaffevm
> - depends on config
> - depends on include
> - depends on kaffeh

Yeah, pretty much everything depends on config, since that's where 
config.h is :) Config.h is the file generated by autpconf which contains 
  preprocessor macros describing a platfrom's features. Like 
HAVE_SOME_FUNCTION.

There is a rather ugly circular dependency at the core of it all: in 
order to build the native libraries, you need the JNI/KNI header files. 
In order to build the header files, you need the class libraries, and a 
'javah' like program. In order to build the class libraries, you need a 
java compiler (kjc in kaffe's case, although other complers can be used, 
too). If you build kaffe's class library on a system with no other java 
compiler, you need to bootstrap kaffe on itself using kjc on a freshly 
compiled kaffe. And so on :(

We've had a prebuilt Klasses.jar for a while in kaffe's CVS. But that 
proved to be too error prone, confusing (why do I still have this bug?), 
and simply immensely space consuming (adding 3 megs of undiffable 
binaries to CVS every few checkins is costly in the long run).

> How I understand this to work (or  my problem). To compile thread.c, 
> kaffeh must be compiled first, this depends on files in kaffe/kaffevm.  
> Once kaffeh is compiled, it is used to generate the header files for 
> java_* and others that are created in include.  These are needed for 
> thread.c to compile.  This may not be all that bad, but what I seen 
> happening next is, kaffeh now depends on 
> kaffe/kaffevm/systems/(unix-jthread|unix-pthread).  Why does kaffeh need 
> to know about the threading implementation (classMethod.h)?

It shouldn't need to know. The problem is that the core vm files in 
kaffe/kaffevm are not modularized enough. Just like you've found out :)

> I guess, would there be interest in ensuring that the dependancies are 
> well defined and in one direction?  How about creating a kaffe/common 
> that would have the files that are common between kaffeh and kaffevm?

Yes. I'd prefer to see the core library split further into a few smaller 
libraries, defined by functionality they expose:
kaffe/corejar : jar and zipfile handling
kaffe/verifier : the verifier should be easy to split off, and contains 
a few files in its own.

and presumably others along the same lines. We can get there by looking 
at what core files are shared between kaffeh and kaffevm and trying to 
separate them into functional libraries. I'd welcome patches in that 
direction. I believe that Guilhem was doing some work to separate the 
different engines more clearly, for example.

cheers,
dalibor topic