[kaffe] Re: [tritonus-user] Tritonus on kaffe

[Dalibor Topic]

Hi Pat,

--- Patrick Tullmann <tullmann@cs.utah.edu> 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