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?