Some days ago I wrote down my experiences with packaging
docbook-defguide. The main (remaining) issues I mentioned were the
resources and the time the package needs to build. Even on an AMD X2 4600+ with
6GB of RAM it needs 7-8 hours.
Today I met with Torsten Werner. He mentioned that there are some more JVMs I could try. So I tested alternatives to GIJ this night. I found this short summary about free JVMs which was some kind of interesting.
I began with
cacao which seemed to be fast, but it was killed very early in
the build process with an
java.lang.OutOfMemory error. Even playing around
-Xmx switches in
buildtools/saxon.sh did not help. So I
dropped it from the list. Seems both
kaffe create similar
problems here and are not suitable for building the package.
Second alternative I tried was
sablevm. It instantaneously threw out some
warnings or errors so I directly dropped it too.
Next JVM was
jamvm. But it was as slow as GIJ. So I dropped it from the list of alternatives too.
Then I found an interesting statement in the article I linked somewhere above.
The author said, that his perfomance test time with GCJ/GIJ reduced from 433 to
9 seconds when he compiled his application into a native executable. So I
took a quick look through the
docbook-defguide build dependencies and found
that Debian already provides a natively compiled Xerces package
libxerces2-java-gcj. But there were no packages for
libxml-commons-resolver1.1-java (#458248) and
docbook-xsl-saxon. So short and dirty: I downloaded the source for these
packages, added the necessary stuff to get natively compiled packages too,
built and installed them. Fortunately packages with native code already existed
for their dependencies JAXP 1.3 and Xerces.
And what should I say: Building the TDG now needs less then 512MB RAM and it
builds in around an hour … even on my system. I will ask the Debian Java
maintainers to add
-gcj packages for Saxon and XML-Commons and fix my own
docbook-xsl-saxon package. This will hopefully help maintaining