Hi, before I go and rewrite class library compilation a little bit, I'd like to hear if anyone has attempted to fix the remaining issues with class library compilation.
Here's a short list of things I don't like with the current way of things: 1. It is inconvenient. When I add new classes to the lot, I have to touch Makefile.am, regenerate Makefile.in, recompile all of kaffe again before I can see if the new classes break when compiled under kaffe with kjc. Using jikes helps a little, but not much. 2. It is broken. At least under IRIX, it's not possible to compile kaffe anymore because the maximum command line length is exceeded. Since the makefile passes all class names that need to be compiled to rebuildLib, the command line can be quite large, actually. 3. It is not flexible. There is no easy way to specify a different mix of classes for rt.jar. Sure, one could hack away at Makefile.am, and go though the recompile-everything/hack Makefile.am a couple of times until it stabilizes. But that's not exactly what I'd call flexible. Kaffe should have an easier way of tailoring rt.jar to one's needs. Embedded developers may not need all the great stuff in the class library. The currently official way of stripping down rt.jar is to remove the classes from it after the compilation, according to FAQ.embedded. That approach can cause trouble if you cut away classes which are used to implement others. It would be better if the users could specify what classes they want in their rt.jar in some less tedious way. They would be greeted by friendly compile time errors instead of ClassNotFoundExceptions at runtime ;) So here's my proposal: I'd like to introduce two new kinds of configuration files into libraries/javalib. We already have bootstrap.classes and I'd like to add similar files for compilation passes and classes to be compiled in a run. * New configuration file: configuration-name.profile Syntax like boostrap.classes. A list of passes that the compiler is supposed to make in order to compile the class library. Each pass is actually a file name. * New configuration files: some-pass-name.files Just a plain list of files. It would contain all the files that need to be compiled together in a single pass. * Makefile.am would be reduced to doing little processing of the *.profile file. It would call rebuildLib with each *.files file from the *.passes file until it's done. * rebuildLib.in would just pass the *.files file name to the compiler as the @files parameter. I think every java compiler accepts this option. Jikes, javac & kjc do, and I think gcj does as well. How does this solve the issues mentioned above? 1. Adding new classes becomes just a matter of adding them into a *.files file. In a case of adding a wholly new set of classes, one could also edit the respective *.profile file to include a new *.files file, and put the classes in the new *.files file. No need to reconfigure or recompile anything. 2. Compiling on platforms with short maximum line length is no longer an issue, as the only thing that gets passed to rebuildLib is a single file name. RebuildLib also only passes a single file name parameter to the compiler. 3. Flexibilty comes into play. Suddendly, if you have a lot of RAM to work with, you can compile kaffe's class library in a single pass. If you have little RAM, and need to split it into more passes, you can. If you need to cut it down to only the classes you need for your app, you can. If someone contributes 'class library profiles' for JDK 1.0, 1.1, 1.2, j2ME etc, you can reduce kaffe's class library to the extent of that platform [1]. If we get some configurations contributed, I'd like to have a --with-class-library-profile=profile [default, single-pass, minimal-ram, hello-world, ...] configuration time option to pick a profile. Before I go off and implement this, I'd like to hear your opinions. best regards, dalibor topic [1] In a limited sense, as you'd still have parts of classes included that don't 'belong' into that release. How to handle such a 'jdk-x.y profile' has been the subject of some discussion between jukka santala and me, but no really good solution materialized. Search kaffe's mailing list archives using mail-archive.com if you want to know more. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
