Hi, On Thu, 8 Oct 2026 at 19:10, Álvaro Herrera <[email protected]> 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
