[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gettext] a .gmo file is not regenerated when its .po file chang
From: |
Benno Schulenberg |
Subject: |
Re: [bug-gettext] a .gmo file is not regenerated when its .po file changed |
Date: |
Tue, 02 Jun 2015 19:41:10 +0200 |
On Tue, Jun 2, 2015, at 03:34, Daiki Ueno wrote:
> Benno Schulenberg <address@hidden> writes:
> > I see you
> > already have introduced the ability to decouple 'make dist'
> > from 'make update-po', and 'make update-po' from 'make
> > tralala.pot'. I can understand why a maintainer would want
> > the first one, but I fail to grasp the use of the second one?
>
> That was a request from GNOME, where they don't check-in POT files into
> the repository [...]
But, but... /no/ project should keep its POT file under version control,
as it is a derived file. However, I see that for example util-linux and
nano do keep their POT file in VCS. Strange. Maybe because the older
gettexts kind of obliged them to do that?
> > But... shouldn't then all "CATALOGS" be replaced with "POFILES" in that
> > stamp-po comment? Otherwise it doesn't make sense to me.
>
> I think you are right, the occurrences of $(CATALOGS) should be
> $(GMOFILES).
Ehm... not $(GMOFILES) but $(POFILES), right? :)
What I don't get is: why are there two recipes for msgmerging PO files?
Tthe "$(POFILES): $(POFILESDEPS)" one, and the ".nop.po-update:" one.
The first gets run when I touch the POT file, the second when I run
'make update-po'. The first recipe uses --update, the second uses an
intermediate file. Why can't the two be melted into a single recipe?
Otherwise the 'touch $$lang.po' will have to be added to the first too.
Benno
--
http://www.fastmail.com - IMAP accessible web-mail