Hi, On Thu, 8 Oct 2026 at 18:41, Peter Eisentraut <[email protected]> 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@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
