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