make update-po@master stops at pg_upgrade

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: make update-po@master stops at pg_upgrade
Date: 2022-07-13 07:08:53
Message-ID: 20220713.160853.453362706160476128.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I'm not sure if it fits -hackers, but seems better than -translators.

I find it annoying that make update-po stops at pg_upgrade on master.
The cause is that a file is renamed from relfilenode.c to
relfilenumber.c so just fixing the name works. (attached first).

On the other hand, basically, every nls.mk contain all *.c files in the
tool's directory plus some in other directories with some exceptions:

a) nls.mk of pg_dump and psql contain some *.h files but they don't
contain a translatable string.

b) nls.mk of ecpglib is missing some files that contain translatable
strings. (adding theses files doesn't change the result of make
update-po, but I'll send another mail for this issue.)

c) nls.mk of pg_waldump, psql, libpq and preproc excludes some *.c
files which don't contain a translatable string.

At least for (a) above, removing them from nls.mk is rather good. For
(b), adding them is also good. For (c), I think few extra files
doesn't make difference.

I wonder if we can use $(wildcard *.c) instead of explicitly
enumerating every *.c file in the directory then maintaining the
list. Since backend does that way, I think we can do that the same way
also for the tools. Attached second does that except for tools that
have only one *.c. The patch doesn't make a difference in the result
of make update-po.

Either will do for me but at least I'd like (a) applied.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
pg_upgrade_nls_mk_relfilenumber.patch text/x-patch 668 bytes
nls_mk_use_wildcard.patch text/x-patch 10.7 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-07-13 07:43:29 Re: Refactor to make use of a common function for GetSubscriptionRelations and GetSubscriptionNotReadyRelations.
Previous Message Amit Langote 2022-07-13 07:03:51 Re: generic plans and "initial" pruning