On Thu Mar 23 11:12:30 2023 +0000, Alexandros Frantzis wrote:
I don't think that that sort of thing belongs in makedep, we should
never have dependencies to files outside of the source tree. Although using the external wayland-protocols dependency is the standard way of dealing with protocols for most projects, it's also absolutely fine to vendor protocol .xml sources if preferred. Since this is the preference for Wine, I will update the MR to include any protocol .xml files as internal driver sources.
Ideally we'd simply ship the generated files like we do for OpenGL,
Vulkan, etc. The .c/.h sources generated by wayland-scanner for the .xml files are only guaranteed to be compatible with the matching libwayland version or any newer version, but not older versions. If we include generated sources, we are effectively forcing an artificial minimum version requirement on libwayland. I say artificial, because normally the Wayland clients only directly use the more public/high-level APIs, so any additional version requirement stemming from the use of lower level marshalling APIs is both implicit and likely not intended. One possibility would be to use an older version of the wayland-scanner to pre-generate files, so that we support a wider range of versions, but then we will be forcing all users to miss out on any marshalling related fixes and improvements from newer versions, even if they have a libwayland that supports them. Generating the .c/.h files at build time moves the minimum version decision to that time, allowing users/distributions to use the latest version that is available to them. Do you think the outlined approach of vendoring protocol .xml files, but still generating .c/.h at build time would be acceptable?
The problem is that if we stick to using an old version of the protocols, we will not be able to use new protocols that fills the gaps Wine may need to functions properly without resorting to using any weird workaround that work half of the time.
Since Wayland is currently evolving rapidly, and many issues were recently addressed in the Wayland protocol, I think **sticking to an old version of the protocol is not a good solution**, as it will prevent Wine to collaborate with the Wayland project to fix any issues that require Wayland protocol change.
But I also understand the worry of @julliard of wanting to make Wine source code as easy to maintain and as stable as possible.
I think the best solution would be to have a custom version `wayland-scanner` that can generate backward compatible code that still support the latest protocols, but I know **it's probably too much work** compared to just using the `wayland-scanner` and the external `wayland-protocols` dependency.
If using a vendor protocol `.xml` with the latest protocols and it can generate backward compatible code with the unmodified outdated `wayland-scanner` version this would be the best solution, but even in this situation **compatibility can be an issue.**
I'm my opinion using the distribution protocol `.xml` **(Current way it's implemented) seems the best solution** that require the less effort to maintain for Wine in the long term, and since it also the way most project already work so it will be easier to find support from the community to maintain the Wayland driver.