[libxkbfile] Update to 1.2.0

[SunBlack]

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

Note:

• Switch away from downloading from GitLab to prevent hash issues
• Removed support of Windows, because of this commit. Since the maintainers have decided to base themselves permanently on a POSICs API that is not part of the C standard, we would always have to revert this change via patch. Since I can't find any dependencies on this library within the vcpkg repository that would cause anything to break, I don't think it's necessary to force Windows support. MinGW should probably still work, but can't test it locally (and sadly there is no CI build here).

[dg0yt]

So the port which is normally empty on non-windows (subject to X_VCPKG_FORCE_VCPKG_X_LIBRARIES) will no longer be tested in windows CI.

At least there are no reverse dependencies.

[SunBlack]

That's sadly true. But do you think it makes sense to create extra Windows compatibility just so that it can be built? Wouldn't it make more sense if at least one CI job set X_VCPKG_FORCE_VCPKG_X_LIBRARIES? Alternatively, a MinGW job would be quite nice. I don't know how widespread it still is, but currently, the information about whether it builds with MinGW or not is probably not correct for some ports.

[BillyONeal]

"make it work on Windows" is half the reason I believe this got added in the first place.

Our normal requirement for something to be in the curated registry is that we have to be able to test it on at least one platform and this kinda breaks that.

[BillyONeal]

vcpkg-team: Given that we were unwilling to take all of the X bits because they required patches that were too big to work on Windows, and we are unable to test this in our default configuration, should we deindex this?

[AenBleidd]

If not talking about Windows, what is the general issue with the X libraries? I have enabled X_VCPKG_FORCE_VCPKG_X_LIBRARIES on my CI flows, and they work well (at least those I use). Why this flag can't be removed for Linux build to enforce building those libraries for Linux?

[AenBleidd]

I have checked the original issue with the strcasecmp() function. AFAIK, this is quite a common case, so maintaining a custom patch with this function reverted looks ok to me. I don't believe this will add any additional significant complexity to the port support.

[SunBlack]

I have checked the original issue with the strcasecmp() function. AFAIK, this is quite a common case, so maintaining a custom patch with this function reverted looks ok to me. I don't believe this will add any additional significant complexity to the port support.

The point here was rather that the maintainers have now made a conscious decision to only support POSIX systems. Currently, the patch would still be manageable, as you would only have to revert the commit as a patch and integrate the existing patch. At present, this would still be okay, even if it would probably result in a merge conflict with every update, meaning that you would always have to check out their repo first to resolve the conflict. However, the bigger problem will arise if they decide to remove the macro that currently encapsulates the alias between their own implementation and the POSIX function and use the function directly everywhere. At that point, at the latest, patching will no longer be a reasonable solution. So the question now is whether to continue with the current solution or make the cut now. It's actually interesting that the ports are built on Windows, even though the X libraries are more likely to target Unix, but don't check whether they are actually still built on the actual target systems. The question is: Which users benefit from these ports? Those who really always need the latest X libraries would probably be well served with an Arch container. Everyone else won't set X_VCPKG_FORCE_VCPKG_X_LIBRARIES anyway, so they wouldn't need these ports either.

[AenBleidd]

Those who really always need the latest X libraries would probably be well served with an Arch container.

I don't agree on that. If you use Arch container, that means that you always build your solution with the latest glibc meaning your application will no longer be backward compatible with the older distros.

[BillyONeal]

If not talking about Windows, what is the general issue with the X libraries?

Our understanding is that almost every customer wants to build something that works on their distro and respects their distro's windowing settings and similar, and thus need to use these libraries from their distro, not custom ones (via vcpkg or otherwise).

There's also the problem that many of the X dependencies are HUGE and people don't want to pay the build time for them.

AFAIK, this is quite a common case, so maintaining a custom patch with this function reverted looks ok to me.

That gets very close to "vcpkg has a custom version of with extra support for things upstream won't support" which makes us the source of support for those things, which we are not in the business of and do not have the expertise or capacity to do. ( This hits at least 2 bullets in https://learn.microsoft.com/vcpkg/contributing/maintainer-guide#patching )

The PRs we ultimately rejected because the patches were too big and/or we could not practically test them (which is why we don't have all the X libraries) were:

• [X* libraries] new ports #21584
• [xwindow] part 6 #26858

[BillyONeal]

I don't think we can compromise on "at least one non-community triplet needs to be able to build the library", meaning that the port becomes empty for non-Windows but the supports cluse excludes windows means we can't take this as currently proposed.

That leaves one of the following:

• The Windows fixing patches like those originally submitted by @Nuemnan-A et al. when these ports were first added need to be kept forward and the existing Windows support needs to keep working, or
• We need a writeup / justification to change the default handling of X_VCPKG_FORCE_VCPKG_X_LIBRARIES so that x64-linux would be that test platform, or
• We would need to promote a triplet that DOES set X_VCPKG_FORCE_VCPKG_X_LIBRARIES to ON to non-community or similar.

@SunBlack please let us know which direction you think we should take. We should probably try to include @Neumann-A in any discussions here as he added these ports initially.

[SunBlack]

I don't think we can compromise on "at least one non-community triplet needs to be able to build the library", meaning that the port becomes empty for non-Windows but the supports cluse excludes windows means we can't take this as currently proposed.

Agree, as otherwise there is no check, that the portfile still matches the code.

That leaves one of the following:

* The Windows fixing patches like those originally submitted by @Nuemnan-A et al. when these ports were first added need to be kept forward and the existing Windows support needs to keep working, or

IMHO not really an option anymore, as they are switching to meson (tried to update libxxf86vm to meson a few minutes ago and failed again). Issues with meson and X libraries:

• Some port require somehow sed (thats why libxxf86vm 1.1.7 is failing on Windows now with meson). Same happened already in [libxscrnsaver] Update to 1.2.5 #49675. As I already saw some X projects which removed the old autoconf build variant, this will be an issue in near feature in multiple ports
• With the switch to meson we need a patch to export symbols. Like in this port or in [libxkbfile] Update to 1.1.3 #49544. As far as I read it wasn't necessary in autoconf due to libtool, which generated the required .def files. This is not the case with meson. That's then nothing is exported. Manallay patching would mean: We test whether the port build sth. and export at least one symbol - but we don't test, whether all necessary things are exported.

Therefore it should be one of the other options

* We need a writeup / justification to change the default handling of `X_VCPKG_FORCE_VCPKG_X_LIBRARIES` so that x64-linux would be that test platform, or

* We would need to promote a triplet that _DOES_ set `X_VCPKG_FORCE_VCPKG_X_LIBRARIES` to ON to non-community or similar.

Another option: Flag the port with X_VCPKG_FORCE_VCPKG_X_LIBRARIES somehow in vcpkg.json similar to supports, e.g. by "system-library": "linux". Meaning: When vcpkg see this flag, he know, he doesn't need to build anything, in case it matches the OS. In this case example: On Linux it won't build anything, but MacOS and Windows it will.

The advantage: The CI could evaluate this automatically (compared to the previous variable) and build accordingly.

Options:

1. If something has changed on the port, it is built. All other system dependencies required by the port are loaded from the build cache (as before for normal ports).
2. If something has changed in the port, it is built. However, all other system dependencies required by the port are not built; instead, the system headers are used (as before under non-Windows).
3. Both variants at the same time

My opinion on this:

1. Good if you want to know that the entire stack within vcpkg still fits together. For example, if there is a breaking change in one port that affects other ports, you would notice it.
2. Good if you want to make sure that the port is still compatible with the other system headers. However, breaking changes between them are not noticeable.
3. Increases the CI time for non-Windows systems. However, this would be the variant that would map the previous test environment (Windows tests the entire stack, all others only against the system headers).

[AenBleidd]

Another option: Flag the port with X_VCPKG_FORCE_VCPKG_X_LIBRARIES somehow in vcpkg.json similar to supports, e.g. by "system-library": "linux".

I don't see this as a good solution unless there would be an option to override it and build on linux as well (but this will make the whole solution more complex).

Personally I would prefer a community triplet with the X_VCPKG_FORCE_VCPKG_X_LIBRARIES flag ON.
This is simple, clear, testable, and doesn't require any major change in the current vcpkg implementation.

[SunBlack]

Another option: Flag the port with X_VCPKG_FORCE_VCPKG_X_LIBRARIES somehow in vcpkg.json similar to supports, e.g. by "system-library": "linux".

I don't see this as a good solution unless there would be an option to override it and build on linux as well (but this will make the whole solution more complex).

That's the idea behind it - similar to --allow-unsupported. I think this is easier than the current way with X_VCPKG_FORCE_VCPKG_X_LIBRARIES.

[AenBleidd]

That's the idea behind it - similar to --allow-unsupported. I think this is easier than the current way with X_VCPKG_FORCE_VCPKG_X_LIBRARIES.

But that means implementing one more flag. And at the moment it's possible to control build on a quite granular way (for example, I want to build X libraries, but don't wan't to build some other libraries (e.g. Wayland libraries IIRC have a similar mechanism but with the different define)), but with the flag similar to --allow-unsupported there will be no way to control it on such a level since it will be just ALL or NOTHING.
And again, custom triplet looks more simple to me and stil doesn't require any changes in vcpkg application itself.

But everything written above is just my POV, and I don't insist on this solution.

[BillyONeal]

• Some port require somehow sed (thats why libxxf86vm 1.1.7 is failing on Windows now with meson). Same happened already in [libxscrnsaver] Update to 1.2.5 #49675. As I already saw some X projects which removed the old autoconf build variant, this will be an issue in near feature in multiple ports

Why can't we just get sed present via vcpkg_acquire_msys?

[BillyONeal]

Personally I would prefer a community triplet with the X_VCPKG_FORCE_VCPKG_X_LIBRARIES flag ON.
This is simple, clear, testable, and doesn't require any major change in the current vcpkg implementation.

Being a community triplet is not sufficient because that still means our PR builds would have no tests for it. If we truly need a new triplet to take this unfortunately I don't know in what timeline we could add such a thing. Maybe we could make the argument now that UWP is getting demoted that we could promote something else but I think arm64-linux is a bigger win for more customers with the available compute budget we have.

[SunBlack]

Personally I would prefer a community triplet with the X_VCPKG_FORCE_VCPKG_X_LIBRARIES flag ON.
This is simple, clear, testable, and doesn't require any major change in the current vcpkg implementation.

Being a community triplet is not sufficient because that still means our PR builds would have no tests for it. If we truly need a new triplet to take this unfortunately I don't know in what timeline we could add such a thing. Maybe we could make the argument now that UWP is getting demoted that we could promote something else but I think arm64-linux is a bigger win for more customers with the available compute budget we have.

Side question: How much is mingw used (compared to arm)?

[dg0yt]

• Having a dynamic non-window triplet in CI is overdue IMHO.
• An illustration of the quirks at the system/vcpkg border is libxft. Typically, the system package would be a shared lib depending on a shared (system) fontconfig and freetype, while every normal port in vcpkg would use the vcpkg ports.
• I'm a little bit skeptical about the community's ability to keep the whole set of X ports in a reasonable state.

[BillyONeal]

• I'm a little bit skeptical about the community's ability to keep the whole set of X ports in a reasonable state.

That is our fear indeed :)

[AenBleidd]

• I'm a little bit skeptical about the community's ability to keep the whole set of X ports in a reasonable state.

That is our fear indeed :)

This sounds like a challenge, you know? xD