Hi Pat, --- Patrick Tullmann <[EMAIL PROTECTED]> wrote: > Dalibor wrote: > > I'm trying to get kaffe's build system to work > with autoconf 2.56 & > > automake 1.7.1 as well as libtool from CVS. If all > goes well, I hope > > to have something to check in by the end of the > week. > > I'd be wary of upgrading the autoconf and configure > requirements for > Kaffe, simply because you'll reduce the number of > folks willing and > able to deal with rebuilding Kaffe's build > infrastructure even further.
You're right, and I have been thinking about this. I don't want to increase the requirements for participating. Upgrading to latest auto* tools could make the life harder for projects syncing with kaffe's CVS like JanosVM, maybe even pushing them to switch over to latest auto* tools, with all the work that implies. I'd rather delay merging in tritonus before I make life harder for people who've been working hard to improve kaffe or new developers. I'll be providing the tritonus patch as a separate download for now, until I get feedback from people whether it works at all. I'll post the URL in a separate mail, when I get it cleaned up and tested on a few systems. We could wait until the *BSDs, Linux distributions and the rest of the world agree to ship automake > 1.7 and autoconf > 2.56 and then upgrade our build scripts because they break with latest versions. Or we could do it now, and live with an even smaller set of build system developers. I don't think that either option is great. > Also, its not clear to me why Kaffe's build system > needs to be > upgraded to build third-party libraries. Shouldn't > this library be > buildable/linkable without being part of Kaffe's > build system? In theory it is buildable. In practice it is quite hard to get it to work. The INSTALL file for tritonus says compiling from CVS is complicated. It involves running autoconf, ant, and then running make a few times and ignoring the errors ... so it's quite messy in my opinion, and doesn't fit in well in the build process kaffe is already using. Tritonus doesn't provide *.am files, or a configure.in file in the CVS, so hacking its build scripts is complicated. My current code fits it into kaffe's auto* tools based build as en extension library, adds a configure option for the sound backend to use, compiles the java libraries, and links the C++ libraries accordingly. Merging and tracking this external library in kaffe would give kaffe a cross-platform, esound based javax.sound implementation, and allow more people interested in writing java sound applications to do so on a free platform, just like merging in GNU JAXP should have made the life easier for people using kaffe to process XML. Both APIs are parts of java 1.4. Tritonus makes things more complicated, as it exposes a bug in libtool 1.4.3. Tritonus is written in C++, and the latest stable release of libtool (1.4.3, used in kaffe) has serious problems when linking shared libraries written in C++. It uses gcc instead of g++ for the linking step, so it doesn't link with libstdc++ and friends. That in turn prevents the shared library from loading, as it can't resolve symbols like cerr anymore. This bug is fixed in libtool CVS. Libtool from CVS depends on a fairly current autoconf, and so on. cheers, 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
