@xclaesse the CI should NOT pass here, because releases.json never got updated. I think maybe this is because comparing tags to releases.json doesn't actually check when new wraps are added without the latter?

ping?

ping?

Upstream has not answered my question yet.

I would merge it as it is using 0.7 as project version and 2.0 as the library
version.
As far as I know this allows resolving dependencies as expected in meson because the
library version overrides the project version in the declared dependency object.

Which version number do they end up writing in the .pc file? I could not immediately tell all their configure code is custom and handwritten.

Which version number do they end up writing in the .pc file? I could not immediately tell all their configure code is custom and handwritten.

Using the liburing-2.0 git tag they will write 0.7 into the pkgconfig file which is wrong and was fixed by1815337f7dbb.
After seeing this commit I think it is correct to use 2.0 everywhere and drop the project and library version separation

Needs to be rebased on master, sorry. :D

Needs to be rebased on master, sorry. :D

No problem ;)

I expect the CI to still fail because the C++ code included in the meson.build file to check certain compiler features include tabs.
Which is detected by sanity_checks.py and apparently not allowed in meson code.
Should I replace the tabs with spaces? In the C++ code?
This is probably way easier than modifying sanity_checks.py to allow tabs in strings.

I expect the CI to still fail because the C++ code included in the meson.build file to check certain compiler features include tabs.
Which is detected by sanity_checks.py and apparently not allowed in meson code.
Should I replace the tabs with spaces? In the C++ code?
This is probably way easier than modifying sanity_checks.py to allow tabs in strings.

I have removed the tabs from the C code strings.

The alternative might involve adding an AST parser, so yeah, that's a lot easier no matter how meh the error is in this highly specific case.

Seems like I missed some tabs. Sorry for all those incremental fixes and force pushes

And as I've merged another PR ahead of yours, releases.json is clashing again... sorry to make you rebase yet again. :D

EDIT: I'll take responsibility for that rebase.

subprojects/packagefiles/liburing/src/include/liburing/compat.h.in seems unfortunate, actually pretty curious why upstream doesn't use a template with a simple sed to replace e.g.#if @HAS__KERNEL_TIMESPEC@ with#if 1

The "typical" way of doing these is that instead of anfoo.h.in, you have afoo.h.meson. This way it won't clash with the existing configuration template file and you can add any needed changes there. Maybe we should loosen the check and also permit.h.in files?

The "typical" way of doing these is that instead of anfoo.h.in, you have afoo.h.meson. This way it won't clash with the existing configuration template file and you can add any needed changes there. Maybe we should loosen the check and also permit.h.in files?

Upstream has no template file they generate the header directly in their custom configure script.
But I have no problem with changing it fromcompat.h.in tocompat.h.meson if that is the typical naming scheme.
Just let me know ;)

That is the current scheme, yes. Changing that should make this pass CI.

That is the current scheme, yes. Changing that should make this pass CI.

Done :)