[libvirt PATCH 2/7] syntax-check: Introduce sc_pot_comments

[Andrea Bolognani]

On Tue, May 17, 2022 at 10:49:47AM +0100, Daniel P. Berrangé wrote:
> On Tue, May 17, 2022 at 02:23:45AM -0700, Andrea Bolognani wrote:
> > On Tue, May 17, 2022 at 11:12:47AM +0200, Peter Krempa wrote:
> > > On Tue, May 17, 2022 at 10:32:12 +0200, Andrea Bolognani wrote:
> > > > +# Before 0.60, meson would sometimes pass options to xgettext in the
> > > > +# wrong order, resulting in unwanted comments showing up in the
> > > > +# potfile after it was refreshed
> > > > +sc_pot_comments:
> > > > +	@if $(GREP) -E '^#\. ' $(pot_file) | $(GREP) -Ev 'TRANSLATORS:'; then \
> > > > +	  echo "Spurious comments in $(pot_file)" 1>&1; \
> > > > +	  exit 1; \
> > > > +	fi
> > >
> > > Ewww. This doesn't feel like a systemic fix. If meson can't generate
> > > them properly, we should make sure to call the tool properly rahter than
> > > just check whether it's broken.
> >
> > Whether meson generates them properly or not is based on a coin flip,
> > which is why it took me so damn long to get to the bottom of it :)
> >
> > meson 0.60 and newer always generate the file correctly. Once all
> > platforms we target have a new enough version we can decide to drop
> > the check; in the meantime, having it will prevent further cruft from
> > sneaking in undetected.
>
> Can you say what has changed in the  xgettext command line that meson
> is running between the fixed & broken release.  I'm not seing any
> obvious difference in git logs for 0.60 that could cause this.

This is the relevant change:

  https://github.com/mesonbuild/meson/commit/bd2fcb268b9ff48797bebb6a2ef94d2741234191#diff-e9d99e08d876e79e48b22f23823c3fa4b1ba48d852daa2186982a480ffa4e8c3R242

Before 0.60, the xgettext arguments coming from the glib preset were
added to a set along with the ones that we provide ourselves, and so
there was no guaranteed ordering when they were later passed to the
command. The commit above switched from a standard Python set to a
mesonlib.OrderedSet, so the ordering is now guaranteed to be always
the expected one.

-- 
Andrea Bolognani / Red Hat / Virtualization