Re: Getting Kaffe into testing, was Re: Accepted kaffe 1:1.1.3-0.2 (powerpc source)
Hi Colin,
Colin Watson wrote:
On Tue, Jan 13, 2004 at 06:55:56PM +0100, Stefan Gybas wrote:
What do the kaffe developers need to know about the build failures in
question? If we knew that, then perhaps a Debian developer with
relatively little specific experience of Java could gather the necessary
information from a test build.
They need to know more developers using kaffe on those platforms who
would like to submit patches to fix the ports, essentially. ;)
While in theory kaffe builds and works on quite a few platforms, in
practice the platforms that work best are the platforms that are used by
the kaffe developers (intel, ppc, linux, freebsd) regularly. Kaffe 1.1.4
should be out in a few weeks, and I doubt the situation will improve
much unless kaffe can attract more developers on non-maintream
architectures to contribute a patch or two to get their architecture up
and running again.
* Triage
The interesting thing is that almost all the build failures actually
come from the class library compilation stage. That's being done with
kaffe's java compiler kjc (written in java), so it's a rather tough test
for the VM. In the release tarball, kaffe.org ships a prebuilt rt.jar
file to avoid the problem for people on smaller/slower platforms
(longest recorded build time was 30 hours, I believe).
This may be a way for debian, too, to fix the build failures, and
schedule the real bug fixing work (crashes, burns) when people using
kaffe on those arhitectures actually report problems (they may not all
want to rebuild the class library, for example).
Another possibility is to use another java compiler in the class library
compilation step. I use jikes 1.18 regularly, for example, for
compilation speed reasons.
Yet another possibility is to try to build the platforms that crash
during the build of the class library with the interpreter engine
enabled instead of a jitter. Interpreter engine *should* be fairly stable.
But that's all triage and not real bug-fixing, really. In order to fix
the bugs, kaffe needs developers intersted in having a free java runtime
on those platforms to fix the (plentyful) compiler warnings, and take
kaffe for a spin with gdb. But if there is no interest, those bugs won't
get fixed, and then triage might be a better solution.
Better suggestions?
Fix the build problems. :) Hey, it built on those architectures in the
past, didn't it?
That doesn't necessarily imply it still would ;) Kaffe's source has been
worked on, the architectures toolchains have been worked on.
One kaffe release (1.1.x) had to be heavily patched for debian because
debian was using a gcc-3.x, where none of the kaffe developers did at
that time. Unfortunately gcc 3.x refused to compile some source that
gcc-2.95 compiled, and I fixed that problem in kaffe, after I read the
debian buildlogs. Other people fixed that problem in debian's kaffe, but
didn't send us the patches, merry confusion everywhere on what was fixed
and what not.
So, I guess, the best way to approach this is to very politely ask
developers on debian-$arch if they are interested in helping kaffe build
(again) on their platforms, and if they would be willing to look at the
FTBFS logs in order to help out with a patch or two. If that doesn't
help, then triage, and wait for bug reports from real users not the
buildd, if that fails, drop the arch.
I wouldn't mind approaching debian-$arch mailing lists myself, but I
would hardly have the time to coordinate such a bug-fixing effort[1],
beside testing the patches with our CVS.
cheers,
dalibor topic
[1] My own backlog of ports I've promised to help with getting kaffe to
build includes m68-netbsd, sparc-netbsd, sparc-solaris2.6, and testing
the patches for arm-linux, among other things I'm involved with.
Reply to: