tarball POTFILE.in errors; 1.9.0 next Sunday proposed (was: Proposal: Release 1.9.0 today)

[Christian Stimming]

Ok,

there are obviously still build problems in a tarball. I propose to plan 
for a 1.9.0 next Sunday. Until then, everyone should at least once do a 
"make dist" and try to compile the resulting tarball from the tarball alone.

Chris Lyttle schrieb:
> on amd64 I get,

Does anyone of the active developers have a amd64 machine at hand? (I 
don't.) I would certainly believe that some tests will fail on amd64 as 
long as this is none of our actively developed target platforms...

> on x86 I get,
> 
> make[3]: Entering directory
> `/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/po'
> INTLTOOL_EXTRACT=../intltool-extract srcdir=../../po ../intltool-update
> --gettext-package gnucash --pot
> can't
> open ../../po/../src/gnome/schemas/apps_gnucash_dialog_scheduled_transctions.schemas.in: No such file or directory at ../intltool-extract line 204.
> /usr/bin/xgettext: error while opening
> "../../po/../src/backend/dwi/qofmap.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[3]: *** [gnucash.pot] Error 1
> make[3]: Leaving directory
> `/home/chris/cvs/gnucash-test/gnucash-1.9.0/_build/po'
> make[2]: *** [check-recursive] Error 1

*sigh* Now this is the generated po/POTFILES.in striking back. There are 
obviously some files in SVN that don't make it into the tarball and 
nobody noticed so far. The generated po/POTFILES.in cannot distinguish 
those from the correct ones. Both 
src/gnome/schemas/apps_gnucash_dialog_scheduled_transctions.schemas.in 
and src/backend/dwi/qofmap.c are not included in the dist target, but 
are included into POTFILES.in by make-gnucash-potfiles because they are 
found in a SVN checkout.

(I wonder why the rule for po/gnucash.pot triggers at all -- it 
shouldn't in the tarball. But anyway, it should be allowed to call this 
rule in the tarball, so POTFILES.in needs to be fixed.)

Here's what we can do:

  #1. Include po/POTFILES.in into SVN again; don't let it be generated 
automatically, but only on the manual rule "make pot"; remove those 
non-distributed files from the SVN version of POTFILES.in. Problem solved.

  #2. Add those non-distributed files into the @ignorepatterns in 
make-gnucash-potfiles. This will fix this particular error from the 
generates POTFILES.in.

  #3. Add some wonderful magic into make-gnucash-potfiles which will be 
able to tell apart the non-distributed files from the distributed ones.

I can't imagine any implementation of #3 that doesn't involve adding an 
extra rule to *all* Makefiles. Has something of "mit Kanonen auf Spatzen 
schießen", literally "Shoot sparrows by a cannon", in english "to break 
a butterfly on a wheel". So either #1 or #2.

Note that eventually #2 isn't any different from having the POTFILES.in 
directly in SVN, #1. It is still possible that someone removes a file 
from the dist target but leaves it in SVN, which will break the #2 
solution, BUT (and that's the not-so-good part) only in the tarball and 
not in the normal SVN build, which means this breakage won't be 
discovered until the release manager tests the tarballs. :-(

Also a problem of the #2 solution is that it is much more subtle and 
less clear how to fix such files that should not be added to 
POTFILES.in. The #1 solution OTOH makes it extremely clear how to fix 
such files, it will show the build errors directly in the SVN build 
which is where it should also be fixed, and it enables the translation 
manager (myself) to edit this file into a form that will really include 
only those files that contain translations.

I propose #1, adding po/POTFILES.in back into SVN and having it 
regenerated only on the manual "make pot" rule.

Christian