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

Hi,

On Thu, 8 Oct 2026 at 19:10, Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>
> On 2026-Oct-08, Peter Eisentraut wrote:
>
> > On 07.10.26 17:35, Nazir Bilal Yavuz wrote:
> > > 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.

I will first work on ensuring it doesn't regenerate when inputs don't
change. Then we can decide if the solution looks good or if we need
another one.

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

I couldn't think of any solution that avoids manual maintenance. I
found a thread [1] that uses wildcard to include each source file but
since there could be files that we explicitly don't want, there should
be still manual maintenance; right? Perhaps including all of the
source files and excluding some is easier than the reverse?

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

--
Regards,
Nazir Bilal Yavuz
Microsoft