$ sudo pbuilder login --save-after-login # echo "sun-java5-jdk shared/accepted-sun-dlj-v1-1 boolean true" debconf-set-selections # echo "sun-java6-jdk shared/accepted-sun-dlj-v1-1 boolean true" debconf-set-selections # exitand voila, problem solved. Thanks to Michael for the tip.
java.lang.OutOfMemory error. Even playing around with the -Xms and -Xmx switches in buildtools/saxon.sh did not help. So I dropped cacao from the list. Seems both cacao and kaffe create similar problems here and are not suitable for building the package.
Second alternative I tried was sablevm. It directly throw 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 fast 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 libsaxon-java, libxml-commons-resolver1.1-java 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 exist (JAXP 1.3 and Xerces) for their dependencies.
And what should I say: Now building the TDG 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 docbook-defguide.
Depends: iceweasel iceape-browser xulrunner, libart-2.0-2 (>= 2.3.18), libatk1.0-0 (>= 1.20.0), libc6 (>= 2.6.1-1), libcairo2 (>= 1.4.0), libgcc1 (>= 1:4.2.1), libgconf2-4 (>= 2.13.5), libgcu0 (<< 0.9), libgcu0 (>= 0.8), libgl1-mesa-glx libgl1, libglade2-0 (>= 1:2.6.1), libglib2.0-0 (>= 2.14.0), libglu1-mesa libglu1, libgnomecanvas2-0 (>= 2.11.1), libgnomeprint2.2-0 (>= 2.17.0), libgnomeprintui2.2-0 (>= 2.17.0), libgnomevfs2-0 (>= 1:2.17.90), libgoffice-0-4 (>= 0.4.2), libgsf-1-114 (>= 1.14.7), libgtk2.0-0 (>= 2.12.0), libgtkglext1, libice6 (>= 1:1.0.0), libnspr4-0d (>= 1.8.0.10), libopenbabel2, liborbit2 (>= 1:2.14.1), libpango1.0-0 (>= 1.18.3), libsm6, libstdc++6 (>= 4.2.1), libx11-6, libxml2 (>= 2.6.27), libxmu6, libxt6, zlib1g (>= 1:1.2.3.3.dfsg-1)and the new Depends field for gcu-plugin:
Depends: libc6 (>= 2.6.1-1), libgcc1 (>= 1:4.2.1), libgcu0 (<< 0.9), libgcu0 (>= 0.8), libglib2.0-0 (>= 2.14.0), libgnomevfs2-0 (>= 1:2.17.90), libgtk2.0-0 (>= 2.12.0), libnspr4-0d (>= 1.8.0.10), libstdc++6 (>= 4.2.1), libx11-6, libxml2 (>= 2.6.29), iceweasel iceape-browser xulrunnerAs another example bluefish now (the next upload) really only shows the necessary dependencies. Compare the current:
Depends: libart-2.0-2 (>= 2.3.18), libaspell15 (>= 0.60), libatk1.0-0 (>= 1.20.0), libbonobo2-0 (>= 2.15.0), libbonoboui2-0 (>= 2.15.1), libc6 (>= 2.6.1-1), libcairo2 (>= 1.4.0), libfontconfig1 (>= 2.4.0), libgconf2-4 (>= 2.13.5), libglib2.0-0 (>= 2.14.0), libgnome2-0 (>= 2.17.3), libgnomecanvas2-0 (>= 2.11.1), libgnomeui-0 (>= 2.17.1), libgnomevfs2-0 (>= 1:2.17.90), libgtk2.0-0 (>= 2.12.0), libice6 (>= 1:1.0.0), liborbit2 (>= 1:2.14.1), libpango1.0-0 (>= 1.18.2), libpcre3 (>= 6.0), libpopt0 (>= 1.10), libsm6, libx11-6, libxcomposite1 (>= 1:0.3-1), libxcursor1 (>> 1.1.2), libxdamage1 (>= 1:1.1), libxext6, libxfixes3 (>= 1:4.0.1), libxi6, libxinerama1, libxrandr2 (>= 2:1.2.0), libxrender1to the “upcoming” Depends field:
Depends: libaspell15 (>= 0.60), libc6 (>= 2.7-1), libglib2.0-0 (>= 2.14.0), libgnomeui-0 (>= 2.17.1), libgnomevfs2-0 (>= 1:2.17.90), libgtk2.0-0 (>= 2.12.0), libpango1.0-0 (>= 1.18.3), libpcre3 (>= 6.0)Nice result. I should check (my) other packages too :) Maybe that’s also something for debichems TODO list.
ifdef statements differ in syntax
ifdef VAR.ifdef VARAM_CONDITIONAL. But we do not use this macro, because it would need to be shipped in aclocal.m4, which is currently not necessary. The code simply sets a variable foo_TRUE to ‘# ‘, if the condition is wrong, or the variable is left empty, if the condition is true:
if test "x$my_condition" != "xno" ; then
AC_SUBST([foo_TRUE], [])
else
AC_SUBST([foo_TRUE], [# ])
fi
FILES = bar @foo_TRUE@FILES += foo
$<, $^, $@, …$ .IMPSRC , $ .ALLSRC , $ .TARGET , … (note, that both *SRC variables hold a list of source files)$ .IMPSRC and falls back to $^. Maybe that’s an alternative, but it’s IMHO not a very good solution. We’ve chosen to write down all prerequisites in a rule instead of using a variable. This is a little bit “harder” to maintain, but it works.myprog: foo.o bar.oand GNU make will automatically create foo.o from foo.c (
.c.o:, ditto for bar.o) and at least link myprog (.o:). But BSD make will only create the object files. There is no final link-step. So we had to include the rule to link the program in the Makefile.Next.