Posts tagged 'familiar'
While I've been on a work and university deadlines induced hiatus a lot of things have happened in the Free Software world. One of those is that the free (as in beer) BitKeeper client is now history and OpenEmbedded switched to monotone. After a bit of struggling with monotone (it's dead slow - 80mins for an initial pull on a P4 2.4GHz, much longer on older hardware) I now have a working OpenEmbedded environment again.
I've upgraded GNU Classpath, JamVM, and SableVM to current versions. Binary packages for Familiar 0.8.x are available here. The dependencies are against more recent packages than what's in Familiar 0.8.2. Try --force-depends to install them - YMMV.
For those who are wondering, I have no plans to add SableVM SDK to OpenEmbedded or ship it as a package for Familiar, since it violates a couple of common distribution rules (and the FHS?). And on embedded devices (which are low on flash space) it doesn't make sense to ship duplicate binaries anyway . Fine grained packaging and sharing binaries/libraries among applications is the rule there.
In related news, I had to remove the included external libraries from the sablevm source tree and patch out any references to them from the Makefile.am's to make autoreconf work with it (That's necessary to replace certain macros with ones that work in a cross compilation environment). I highly recommend running autoreconf to sanity check the autotools input files before releasing stuff like that.
I'd like to point out one more idea in addition to Michael's list.
4) Supporting a finer grained packaging.
What do I mean by this? For an application specific runtime environment it's rather easy to identify stuff you don't want. It's very unlikely that you'll need AWT/Swing on a headless webserver. Following Michael's strategy 1), you'll build classpath with --disable-gtk-peer, possibly remove unused classes from glibj.zip, and you're finished.
However, this doesn't work too well for distributions (like Familiar) which aim to provide a universally usable set of packages. This "one-size-fits-all" approach sounds like it has to collid with the aim of consuming as little precious flash space as possible, doesn't it?
Well, the easy way out - packaging different build configurations - isn't an option really, since that would result in conflicting packages and a general maintenance nightmare.
A more clever way is to use one build time configuration covering a wide range of use cases and to split the result into as many packages as reasonably possible. E.g., the current kernel packaging code in OpenEmbedded creates one package per kernel module. The same goes for GStreamer modules and glibc localedata just to name a few. This also helps reduce runtime dependencies for core functionality of a given software component (which isn't a new idea of course if you look at gnuplot in debian for example).
Obviously, I'd like GNU Classpath to support something similar. The native libraries (libgtkpeer.so in particular) can be packaged separately already. What's left is one big (in embedded terms rather giant) glibj.zip. Splitting that up isn't a trivial task due to partly less than obvious (java) package interdependencies etc.
Any pointers as to how this could be accomplished would be appreciated (packaging AWT/Swing separately is what users request most frequently btw).
OpenEmbedded is a cross compilation aware build system (consisting of a set of tools and package description files) aimed at building entire (currently Linux based) distributions from sources. Examples for distributions using it today are Familiar and OpenZaurus.
So what's in already?
- GNU Classpath (built with jikes)
- fastjar (available at build time for jar creation)
- Jikes (available both at build time and as a package)
- Kaffe (work in progress. builds but at least on ARM doesn't work yet.)
The road ahead obviously includes cross compilation to native code using gcj. Basically it should be as simple as enabling gcj in the gcc-cross build, but I haven't got to looking into that closely yet.
The issues with SableVM I mentioned earlier appear to have been fixed in SableVM 1.11.x. The apparently ARM specific random crashes don't seem to happen either. Good job guys!
JamVM 1.3.0 is out.
JamVM running on an iPAQ H3800.
A simple demo application using AWT and Gtk+ peers.
Actually plotting a function.
And another one.
It is kind of sad to hear that "the AWT/Swing in 1.1.10 and current staging are horribly broken".
In other news, JamVM 1.2.5 appears to work fine with GNU Classpath 0.14 (at least for AWT applications). This is the first JVM to run AWT apps flawlessly on my iPAQ (and will be the first free one to do so in Familiar as part of the next release).