0.60 fails to build GNOME components

[seb128]

Using the new meson 0.60, either from upstream or Debian, GNOME components started to fail to build

Example of the eog snap build
https://launchpadlibrarian.net/565502418/buildlog_snap_ubuntu_focal_amd64_eog_BUILDING.txt.gz

Configuring org.gnome.eog.desktop.in using configuration

../src/data/meson.build:25:5: ERROR: Function does not take positional arguments.

Trying to build the current eog deb in Ubuntu with the new meson 0.60 deb from Debian unstable leads to a similar error

[albertvaka]

The function call that causes the error is i18n.merge_file because it's called with a positional argument. You can see an example on Nautilus (which also fails): https://gitlab.gnome.org/GNOME/nautilus/-/blob/7b469dfa/data/meson.build#L23

However, according to the docs:

This posarg is optional since 0.60.0. It defaults to the basename of the first output.

So this should be allowed. The problem might have been introduced in commit 6b1a800

[eli-schwartz]

This actually changed in 61f2866.

And the docs that are relevant here are https://mesonbuild.com/i18n-module.html#i18nmerge_file

This merges translations into a text file using msgfmt. See custom_tgt for normal keywords. In addition it accepts these keywords:

It doesn't accept the positional arguments of custom_target, only the keyword arguments. However, that did not used to be type-checked, so before 0.60 if you passed a positional argument to merge_file() it would be totally ignored, but not raise an error.

[albertvaka]

Thanks for your response! 🙂 So if I understand correctly, this argument was being silently ignored on older versions of Meson and should be removed on Gnome's side?

Maybe the merge_file docs should be updated to mention it only accepts the keyword arguments from custom_target, at least for me with the current wording this isn't obvious.

[seb128]

Could the error be turned into a warning at least for a transition period to let upstreams fix their build and get new releases out?

[eli-schwartz]

Maybe the merge_file docs should be updated to mention it only accepts the keyword arguments from custom_target, at least for me with the current wording this isn't obvious.

We have some very nice, modern templating for the reference manual that automatically provides function signatures with typed descriptions. Sadly, it isn't wired up to the modules documentation... Even so, anywhere else that positional arguments are accepted and used, they are mentioned, and here, their intentional absence/omission is the clue.

Could the error be turned into a warning at least for a transition period to let upstreams fix their build and get new releases out?

As I mentioned in IRC, it's very hard to know exactly which things every project out there is doing that violates the documentation, and hence is directly relying on our buggy implementation. We did publish release candidates, and ask people to use them.

[xclaesse]

We should turn it into a deprecation warning for 0.60.1 and keep it removed in master. Does it break many GNOME projects? I guess it's the kind of mistake that got copy pasted everywhere?

[ondrejholy]

As per https://github.com/search?q=org%3AGNOME+merge_file&type=code, it seems that Nautilus and EOG are not definitely the only ones.

This might be interesting for @inigomartinez, who ported many of the GNOME projects...

[inigomartinez]

I noticed it when trying upstream meson but I though that it could be an unfinished wip code because meson tries to be backwards compatible. I'll be looking forward to the fix.

Thanks @ondrejholy!

[xclaesse]

The fix is there: #9445. But in the meantime please fix all GNOME projects that rely on that behaviour because it will become an hard error again in 0.61.0.

[inigomartinez]

Wouldn't be better to let this as a deprecated warning for some more versions?

[eli-schwartz]

There is more than enough time between now and the next feature release of meson, for projects to fix their code.

It's a simple and backwards-compatible fix, just remove a completely ignored argument and backport it to any stable maintenance branches you have.

It's not even incorrect to fail here. It was never allowed. Meson has added a lot of improved type checking in recent years, which made many things that used to be silently ignored, turn into errors. We didn't add deprecation warnings for any of it. Anyone who is passing incorrect arguments should in fact be told what they're doing isn't actually doing what they think it is doing, and their meson.build files are buggy.

That's not a matter of backwards compatibility! That is a matter of bug-level compatibility.

This deprecation warning is being added as a courtesy gesture, because it turns out this one thing is surprisingly common among related projects and we want to give you time to fix things before your projects become unbuildable.

This is NOT permission to keep on using invalid arguments for another few years and another few major versions of meson! Fixing these bugs in the meson.build files should be prioritized IMO.

[eli-schwartz]

Downgraded to a deprecation warning in the maintenance branch, once we release 0.60.1 you will have a whole dev cycle to find and fix these issues.