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
_______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
