--- Patrick Tullmann <[EMAIL PROTECTED]> wrote: > Hey Dalibor, > > I didn't realize Tritonus provided part of JDK1.4 > compatibility. I > see why you're trying to get it into the tree. Any > chance there is a > simple hacky fix to kaffe's libtool to get it to > link c++ correctly?
Maybe, I think I saw some patches in the libtool mailing list archives from some Mandrake Linux guys. You can try to merge it with what we have (1.4.3), if you wish. On the other hand, if that means "supporting" our own version of libtool, I'd rather not go there, but just take stuff from the upstream CVS, and remerge when some significant bug is fixed. > Since I think we're going to get bitten whatever we > do, I think we > should probably be doing more to reduce the need for > developers to > re-build Makefiles and configure. For example, the > change proposed a > while ago to remove the list of java sources from > the Makefiles would > be a really good step. I can work on that a bit > unless someone else > already has it working... I agree. Just because someone would like to test a class or two from Classpath, they should not have to go through the whole 'edit libraries/javalib/Makefile.am, run developers/autogen.sh, reconfigure, compile, and wait for a while until it's finished' procedure. I find that quite time consuming when I'm merging in new classes, given that each (configure; compile; test) cycle takes about 10 minutes on my current development machine. So please go ahead, and make it better. That frustration was one of the reasons why I proposed ant for the job a few months ago. I've changed my mind since, as suporting ant would mean that we need to pull in javax.xml into Klasses.jar.bootstrap, and all other classes for XML support. That would turn Klasses.jar.bootstrap into the big, cvs-unfriendly thing that Klasses.jar was. I wouldn't want that. Ant has one great feature, though: given a path of directories in the build file (equivalent to the makefile in make-terms) it finds all *.java files and compiles them, without the developer having to spend time maintaining a current list of classes. So if you plan to work on it, some code that does the equivalent of: find $PACKAGE-BATCH -name "*.java" > class-files $JAVAC @class-files would be great. the ">" is there because as the class library grows, enumerating it is going to exceed the maximum command line length on most systems. It does so on IRIX already, which is one of the reasons why I have split Klasses_jar_SRCS in libraries/javalib/Makefile.am . The other is amount of memory required to build kaffe. It's not very funny to watch the garbage collector crawl through the swap space for a day. ;) My idea would be to have package lists in a separate file, say classlib.packagelist. The format could be like that of bootstrap.classlist, with a small addition to allow to specify multiple batches of packages. Having it separately, means being independant of auto* tools for class library issues. What do you think? > I imagine doing something similar for the extensions > library is a bit > too much (since libtool has to do linking of the > generated objects). > Any other ideas? Anyone else find themselves > running > developers/autogen too much? I think I'll be migrating the java bits of the extension library into the main library directory eventually. Sometime next year, at the moment I'm busy with javax.sound, and if we get that in, I'll be busy fixing the damage the transition to latest auto* tools would have done ;) I don't know about the native libraries, but I assume that the situation is similar. I think it would harder to flexibilize the build process for native libraries, because of libtool. Maybe that would be a nice addition to configure.in: regenerate Makefile.in & Makefile when a Makefile.am file is younger than its heirs. Just-in-time configuration ;) best regards, dalibor topic __________________________________________________ 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