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

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.