Rodney Dawes blogged in reply to my previous blog entry on Hammering the intltool trouble. First of all, blog discussions suck, they suck less if they are carried on in the comments section of a blog entry, but i agree with Rodney that this is still not as helpful as Bugzilla or email conversations are. Coincidentally, the actual issue, namely Beast‘s intltool patch has been addressed in a private email discussion in 2005 and 2006 in which Rodney got Cc:-ed and also replied. That thread also linked to a version of the Beast intltool-extract.in patch. It didn’t seem like this would go into intltool though, so we simply continued to maintain our patched version. In any case, if Rodney prefers to have this issue tracked by Bugzilla, that’s fine, here’s the new bug report which describes our scenario and has the patch attached: Bug 358495 – support for multiline scheme strings.
So I’ve finally had enough trouble with kludging around the different bits and odds of intltool. For several years now, the Beast project has to maintain a patch against intltool to apply after
intltoolize --force --copy. The patch must be applied in order to enable translation of multi line scheme strings, and to allow custom recursive Makefile rules (which usually break due to po/Makefile.in.in). Most often the patches would not apply on systems other than mine, because they didn’t cover all stock intltool versions or would still fail for matching versions because of conflicts with patches applied to intltool during distribution packaging. The latest annoyance we ran into were m4 macro incompatibilities that for a variety of reasons were once more an issue not easily worked around.
Beast SVN now simply contains the copied and patched intltool files (0.35.0) so other developers are finally able again to build Beast from SVN without any autogen.sh trouble and pass all of
make check (which also checks whether scheme strings got properly merged into .po files). After all, it’s not that many files anyway:
acintltool.m4 intltool-extract.in intltool-merge.in intltool-update.in po/Makefile.intltool
A few months ago, i migrated the beast CVS module to automake-1.9. I’ve been working on fixing the various issues this change involved ever since…
At this point, I’m stuck in the end phase of getting make distcheck to work, and ran into a rather unpleasant issue:
make: Entering directory `/usr/src/beast/beast-0.7.0/_build/po' INTLTOOL_EXTRACT=../intltool-extract srcdir=../../po ../intltool-update --gettext-package beast-v0.7.0 --pot /usr/bin/xgettext: error while opening "../../po/../drivers/bse-alsa/bsemididevice-alsa.c" for reading: No such file or directory ERROR: xgettext failed to generate PO template file. Please consult error message above if there is any. make: *** [beast-v0.7.0.pot] Error 1
What happens basically is: make distcheck in automake-1.9 creates a tarball, builds and installs the tarball, does make check and then uninstalls and checks no files are left after uninstall (which is a hairy issue in itself due to update-mime-database(1) leaving stale files). After that, it tries to also
make dist distcleancheck and this is where the fun begins. In order to make dist in the build tree of the distributed tarball, po/Makefile.in attempts to update all .po files for which it needs $(GETTEXT_PACKAGE).pot (for beast, that’s beast-v0.7.0.pot). Creating the .pot file however does require all source files listed in POTFILES.in, and beast is deliberately NOT shipping all the source files listed in there.
Why is beast not shipping all POTFILES.in referenced sources?
The reasons for not shipping all source files in the main tarball are manifold, for the moment, let me just say we split up a beast release into multiple packages because different components are updated at different intervals, and because we need to partition dependencies reasonably. This is rather uninteresting for translators though who just need to translate the strings of “the beast project” as a whole. Which is why the beast CVS module has only one POTFILES.in that lists all translatable source files from CVS, regardless of the actual release tarball they are shipped in. This is obviously the best solution for the translators and for release maintenance.
But it is not a solution automake-1.9 likes.
At this point, I’m stuck at this problem being unsolved, I’m not even entirely sure who’s at fault here. Is the beast project really so wired in shipping multiple tarballs but wanting only a single translation entry point for translators? Or, is intltool at fault because it recreates beast-v0.7.0.pot instead of shipping it or leaving the .po files untouched? Or is it automake-1.9 which tries to ensure that build trees from distribution tarballs can pass make dist again?
I’m inclined to say giving up
make dist for anything that is not a correctly built CVS tree would be the best for the next beast release and certainly weights in far less than giving up on any of the other preconditions that led to this problem. However I’m not so sure that removing
make dist distcleancheck from automake’s distcheck target would make sense for other projects as well. And as things stand, automake-1.9 doesn’t allow for removing these targets from distcheck anyways…
Even though the whole situation is a bit involved, comments are very appreciated… 😉