supprted meson version policy clarification

[pobrn]

While updating lua to 5.5 in #2573, the minimal required meson version was updated to meson_version: '>= 0.63.0' because the CI was saying that c_std cannot be used in subproject default_options before 0.63.0.

However, CI was still complaining, and to me the reason wasn't clear. The readme states

Newly added or updated ports in this repository require Meson ≥ 0.56.

so I thought requiring 0.63.0 is fine.

I had gone through the CI pipeline and found that that there is a check (test_meson_version_deps) that only runs if the TEST_MESON_VERSION_DEPS env var is defined, which will forcefully set the meson_version in the project() call to 0.56.0.

Wouldn't it be clearer to state that

Newly added or updated ports in this repository must have meson_version: '>= 0.56.0'.

or something similar?

[pobrn]

#2516 seems to be the one to have introduced this. It appears to me that it effectively introduces a maximum meson version as well (short of if meson.version().version_compare('>= ...')).

[eli-schwartz]

there is a check (test_meson_version_deps) that only runs if the TEST_MESON_VERSION_DEPS env var is defined, which will forcefully set the meson_version in the project() call to 0.56.0.

My stance is that this is a very unfortunate bug and needs to be fixed so that you can do what you were trying to do.

[bgilbert]

The purpose of `test_meson_version_deps` is for CI to collect and report all the reasons that a wrap needs a Meson version newer than the repository's minimum, 0.56. We don't report dependencies older than that because we wouldn't reduce the wrap's declared minimum even if we technically could. The CI report never blocks merging, and is not considered to be a problem unless the wrap requires a newer version than the one it declares.

…

Message ID: ***@***.***>

[eli-schwartz]

The CI report never blocks merging, and is not considered to be a problem unless the wrap requires a newer version than the one it declares.

And yet, it is a bug in the CI scripts if there is an entire category of situations where:

• red X statuses appear because the informational status messages crashed
• contributors can't tell that it's supposed to be ignored
• maintainers have to investigate what matters and what doesn't, because they can't take advantage of "the PR passed all status checks" to know that they don't have to drill deeper
• apparently, not all maintainers realize that it is supposed to be ignored, because @neheb considered it to block merging and told the contributor to change the contributed wrap and stop using >=0.63.0 and start using 0.56.0 instead

[bgilbert]

That test doesn't cause a red X in the CI summary unless it crashes outright, which doesn't happen often and is certainly a bug that should be investigated. I'm not in a position to check right now, but I believe it can happen when the Meson rewriter fails to change the wrap's minimum version, which can be caused by various deficiencies in the rewriter. Sometimes it can be worked around by restructuring the logic in the wrap. @neheb has long had a policy of avoiding the >=0.63.0 dependency when it arises, which I don't 100% agree with, but have gone along with for my own PRs when it is straightforward to do so. Please feel free to pursue a consensus there.

[neheb]

It's a bit of a lie to claim older than 0.63 compatibility while having default_options used in wraps.

Maybe moving forward it could be suggested to explicitly use 0.63 features. https://mesonbuild.com/Release-notes-for-0-63-0.html

add_project_dependencies seems like an innocent way to do so.