Re: Adding init-po and update-po targets to the meson build system

On 2026-Oct-08, Peter Eisentraut wrote:

> On 07.10.26 17:35, Nazir Bilal Yavuz wrote:
> > I think the biggest problem is the nls.mk files. autoconf read these
> > files to generate *.pot files but meson can't read these nls.mk files
> > natively. So, my solution is switching to using nls.json files instead
> > of nls.mk files and having a Perl script so that the autoconf system
> > can parse these nls.json files and read them as nls.mk files as
> > before.
>
> I would also be content if we ported init-po and update-po idiomatically to
> meson and removed them from the makefiles. These targets are not needed by
> most developers or package builders, so we could restrict how they are
> available.

OK, that works for me. Most translators just download the .po files
from the babel.postgresql.org server, so they don't need the build
targets. Babel itself, of course, does need some way to run these, but
it can use meson just fine. (Except for branches 14 and 15, of course.)

> > 1. Can init-po and update-po meson targets regenerate *.pot files on
> > every run or should these files be tracked and regenerated only when
> > inputs change?
> > -- I am asking this because implementing the prior one is simpler.
> > Latter one requires more complicated changes.
>
> It might not be super important, but it would be intellectually more
> satisfying if they worked like normal file-updating targets. But I'm
> suspicious why this is a question. I mean, if we didn't need them to be
> timestamp-tracking makefile targets, we could have implemented them as shell
> scripts and side-stepped this whole problem?

In practice we do generate these files on every run, because their
respective source files (essentially every single .c in the tree) change
with every commit; the only reason what we have doesn't change the files
continuously, is because those files are not source-tracked anywhere.

Now, that applies to the src/backend/po/*.pot files, which is where most
of the lively git activity takes place. It's not true for most other
tools in src/bin. But I suspect they are small enough that regenerating
whole files each time is not a problem either.

> > 2. How closely must the output from meson and autoconf match?
> > -- Should meson preserve autoconf’s source-reference paths and
> > ordering exactly, or are differences acceptable? In particular,
> > generated sources can produce build-tree relative references through
> > their #line directives. Should we normalize them?
>
> Yes, the build-tree relative references are already a problem with autoconf
> vpath builds, and I would like to get that fixed.

+1

> > Do you have anything else in mind?
>
> There is also a the problem that whenever a source file is added, it needs
> to be added to nls.mk manually. It would be nice to get rid of that
> requirement, if we're going to make significant changes to this. (This would
> also reduce the scope of nls.mk/nls.json/whatever.) There have been one or
> two attempts to address this in the past, which didn't work for some edge
> case reasons. I don't have them handy, but we should look that up. The
> simple and obvious solution might not be sufficient.

I think the problem is that we have generated files whose strings we
want (say, generated by Perl code), and other generated files whose
strings we do not want (e.g., those generated from .l and .y files.)
Also, files like xlogreader.c have to be included in several different
catalogs. We did discuss having a way to generate catalogs by
catenating pieces from several source files though (src/common in
particular), to avoid duplicate translations.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Escucha y olvidarás; ve y recordarás; haz y entenderás" (Confucio)