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

Hi,

On Thu, 8 Oct 2026 at 18:41, Peter Eisentraut <peter(at)eisentraut(dot)org> 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.

Do you mean removing init-po and update-po but preserving the
install-po in the makefiles? Or can we remove them altogether?

> > 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?

I meant preserving that behavior in autoconf but not having it in
meson. You are right, I didn't consider using a shell script because I
was too focused on transferring the behavior.

I will work on ensuring it doesn't regenerate when inputs don't
change. If we dislike the result, we can consider another solution,
like you suggested.

> > 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.

Got it.

> > 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 found this thread 'make update-po(at)master stops at pg_upgrade' [1]. I
will reply to that thread.

[1] https://postgr.es/m/flat/20220713.160853.453362706160476128.horikyota.ntt%40gmail.com

--
Regards,
Nazir Bilal Yavuz
Microsoft