Created attachment 50116 [details] [review]
the patch

The problem was in the interaction between gettext macros and IT_PROG_INTLTOOL.
This patch fixes it.

Moreover, it has the following advantages:

1) It introduces macro IT_PO_SUBDIR, which can be called separately. In the
future, this will help projects with multiple po directories, like the Gnumeric
spreadsheet. (GNU gettext supports multiple po directories since 0.10.38.)

2) The sed script to create POTFILES is now only in intltool.m4. 
Makefile.in.in no longer has a copy of it, thus things like bug #171330 will
not happen again.

Apply by "patch -p1", after applying the patch for bug #311870.

When I patched and reinstalled intltool, the above procedure gave a clean build,
which then passed "make distcheck".

Created attachment 51651 [details] [review]
fixed patch

I fixed a bug in the stamp-it rule in Makefile.in.in and regenerated the patch
against CVS HEAD.

OK to commit?

The patch certainly is an improvement, but I'm still unable to use intltool
together with AM_GNU_GETTEXT in Epiphany: make dist fails with tons of messages
like this:
cp: cannot stat `../../po/../../po/am.po': No such file or directory
(in a builddir != srcdir build, which works with AM_GLIB_GNU_GETTEXT)

Oh and there seems to be a problem with generating files in po/, POTFILES &
Makefile are created twice:

config.status: executing intltool commands
config.status: executing depfiles commands
config.status: executing default-1 commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
config.status: executing default-2 commands
config.status: creating po/POTFILES
config.status: creating po/Makefile

The diff between latest gettext (0.14.5) and intltool's Makefile.in.in is rather
large. Among the changes is a change to install directory for the catalogues:
gettext now always installs them in $(datadir)/locale while intltool still uses
$(datadir)/locale and $(libdir)/locale depending on whether the extension is
.gmo or not.

Thank you Christian for testing this.  Regarding your problems:

> cp: cannot stat `../../po/../../po/am.po': No such file or directory

The problem is that with modern Gettext, POFILES contains things like
$(srcdir)/xy.po .
With the ancient glib-gettext.m4, you get only "xy.po", without the prefix.

To be compatible with both, intltool has to adjust the "dist" rule, see the
patch below.

> config.status: executing default-1 commands
> config.status: creating po/POTFILES
> config.status: creating po/Makefile
> config.status: executing default-2 commands
> config.status: creating po/POTFILES
> config.status: creating po/Makefile

It looks as if AM_GNU_GETTEXT were called twice.  Could you please try to look
at it?

> [GNU] gettext now always installs [catalogues] in $(datadir)/locale while
> intltool still uses $(datadir)/locale and $(libdir)/locale depending on
> whether the extension is .gmo or not.

Yes, that is probably dead code.  But you could remove it only if you removed
the check for CATOBJEXT from glib-gettext.m4 .

I don't want to waste time patching glib-gettext.m4; I think we should first
make intltool compatible with GNU gettext, and then drop the whole glib-gettext.
(AM_GLIB_GNU_GETTEXT will then become an alias for AM_GNU_GETTEXT.)

> The diff between latest gettext (0.14.5) and intltool's Makefile.in.in is
> rather large.

Yes, it is.  It will take a lot of work to make them more similar.  Even then,
the intltool one will have to have some backward compatibility quirks (like the
patch for two forms of POFILES or for CATOBJEXT variants, both discussed above).

... and a year or two after glib-gettext is nuked we might be able to drop
intltool/Makefile.in.in and rely on the one provided by gettext.

... but by that time, at 2009, Makefile.in.in will be deprecated, because
Automake will be able to handle the po directory correctly.  So we'll actually
drop our Makefile.in.in to gain compatibility with Automake 1.14.

So it's really a long time run.  But we should start now, so we have a change to
catch up.

Created attachment 52454 [details] [review]
fix the vpath build

This patch fixes two problems for srcdir != builddir.  (The second one was
reported by Christian Persch, see above.)

Thanks, the additional patch (attachment.cgi 52454) fixes "make dist" for me.

>> config.status: executing default-1 commands
>> config.status: creating po/POTFILES
>> config.status: creating po/Makefile
>> config.status: executing default-2 commands
>> config.status: creating po/POTFILES
>> config.status: creating po/Makefile
>
>It looks as if AM_GNU_GETTEXT were called twice.  Could you please try to look
>at it?

No, I only use AM_GNU_GETTEXT once. It came from AM_PO_SUBDIRS([po]); apparently
it already uses that by default. Removing it fixed the problem.

>> [GNU] gettext now always installs [catalogues] in $(datadir)/locale while
>> intltool still uses $(datadir)/locale and $(libdir)/locale depending on
>> whether the extension is .gmo or not.
>
>Yes, that is probably dead code.  But you could remove it only if you removed
>the check for CATOBJEXT from glib-gettext.m4 .

The problem is that you need to know the install directory, to call
bindtextdomain with it. glib-gettext has AM_GLIB_DEFINE_LOCALEDIR which takes
that into account...

Yes AM_GNU_GETTEXT calls AM_PO_SUBDIRS([po]) and it is documented.
It was a mistake to call it explicitly.

About CATOBJEXT: I think it is reasonable to suppose that the old branch is
never used, ie. that CATALOGS always contains *.gmo files.

(But if you want to remove the .mo alternative from intltool, you have to remove
it from glib-gettext.m4 first.)

I've committed the minor srcdir/builddir patch. Looking at the other patch now.

Committed the gnu gettext patching to cvs.