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… ;)