classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Working On Classpath


From: Dalibor Topic
Subject: Re: Working On Classpath
Date: Thu, 27 May 2004 21:12:27 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040421

Hallo Thomas,

Thomas Zander wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 27 May 2004 12:17, Andrew John Hughes wrote:

since I still can't apt-get it, its not on my radar.  (I'm wondering
how many distro's ship kaffe.)

Kaffe is in Debian stable and unstable

Hmm, I use testing..

Oh, it's stuck in unstable because it doesn't bootstrap on most debian platforms, save for the popular ones, with active developers on them. 1.1.5 will be better in that respect, hopefully. It's unpleasant, for sure. It's likely to remain broken on non-mainstream platforms where we don't have developers to fix the problems. It's a bit of a bootstrap problem in itself: you need to have a working runtime to attract developers, but to have a working runtime on a variaty of platforms you need the developers to maintain the ports ... Maintainance is the hardest bit, really. Most of Kaffe's 50+ ports have worked on the ported platforms at some point in time. But as the platforms develop, the toolchains develop, and kaffe's core progresses, things break. If there is noone around to fix them, they stay broken. :(

So, Ant simulates make's functionality, but there
is nothing to simulate detecting the JVM as the autotools can do (or, if
there is, you don't see it in any current uses of Ant).

ant is a shell-script; it does its best to look for java. It uses JAVACMD, or JAVA_HOME if it can't find a java in the path. I'm not sure this answers your concerns though, and still expects a fully implemented JVM.

Well, ant actually looks for some unspecified acpects of an sdk installation: it assumes that there is a tools.jar, for example, and cries foul if it can't find it. When it can't find Sun's javac, it refuses to use anything else, unless you rub its nose (-Dbuild.compiler) at kjc or jikes. Fortunately, people have taken care of extending ant and providing generic javac tasks for jikes and kjc.

On the other hand, though, Javah task still seems to try to call some Sun internal class directly, which of course doesn't work well with free runtimes. So does Native2Asci, and a few other tasks. Javah is particularly unpleasant, since that's something you'd like to have if you need to deal with JNI libraries, like Classpath does.

I'd say that for some tasks, unfortunately, ant expects more than a fully implemented JVM: it expects a Sun-derived runtime, and nothing else :) But fortunately, that could be fixed, if someone volunteered to make ant fully runtime-agnostic.

If [the autotools] are flexible enough to
also work with Java code (which they probably predate), this is an
advantage of their design.


That is something they can't do; they can call jikes from the command line; but that is a LOT slower then ant with jikes, or ant with javac. This is because a) ant knows which 'clusters' of files have changed and passes them all to the compiler in one compile-run, and b) ant can do dependency checking (which file needs a recompile because it depends on a changed one) by reading the class files.

The only real, big problem autotools have wrt Java (in my opinion) is getting good dependency tracking information into the build. But that's not that critical with jikes on a fast box, a full rebuild of Kaffe's class libraries takes just a few minutes. If you need incremental recompilation, compile all your files at once (preferably using @large-file-list-file), use jikes with '++' option for incremental compilation, and hit return when appropriate, i.e. when you'd normally call ant :)

cheers,
dalibor topic




reply via email to

[Prev in Thread] Current Thread [Next in Thread]