[waffle] [PATCH] wayland: Wrap wl_proxy_marshal_constructor_versioned v2

[Chad Versace]

On Wed 22 Jun 2016, Jason Ekstrand wrote:
> On Tue, Jun 21, 2016 at 9:06 PM, Chad Versace <chad.versace at intel.com>
> wrote:
> 
> > On Mon 20 Jun 2016, Chad Versace wrote:

> > Everyone, thanks for the lengthy discussion. The winner is... Michel's
> > patch v2, which is basically Emil's and SDL's position.
> >
> > I decided against importing any Wayland headers, because the Wayland
> > headers actually contain a lot of inline function *definitions*. When
> > upstream Wayland applies bugfixes and improvements to those functions,
> > by not using imported headers Waffle automatically receives the bugfixes
> > and improvements simply by being rebuilt; this seems to be the intent of
> > the Wayland authors for client projects. If Waffle were to use imported
> > headers then, to receive the same improvements, someone (likely me)
> > would need to diligently keep the imported headers up-to-date.
> >
> > As a bonus, Michel's patch is considerably smaller and requires less
> > maintenance than an import-some-headers patch.
> >
> > And Michel's patch provides correct behavior, at least in my opinion:
> >
> >     - If a user or distro builds libwaffle against wayland < 1.10, then
> >       that same libwaffle will continue to work with wayland >= 1.10.
> >
> >     - If a user or distro builds libwaffle against wayland == 1.10, then
> >       the libwaffle will correctly emit an informative error message and
> >       fail if it dlopens a libwayland-client < 1.10, thanks to the 'goto
> >       error' in
> > src/waffle/wayland/waylan_wrapper.c:RETRIEVE_WL_CLIENT_SYMBOL.
> >       Specifically, the libwaffle will not crash or do undefined
> >       behavior; it gracefully emits an error and fails responsibly.
> >
> 
> This makes me a bit sad.  One of the problems that Michael's patch does
> *not* solve is that, thanks to a Wayland header update (yay improvements!)
> the waffle build broke.  All that's been accomplished on that front is that
> the problem is papered over (we added the new entrypoing) and the next time
> a Wayland header update comes along that uses another new entrypoint,
> waffle will break again.  Maybe this is considered acceptable; that's not
> really my call.

It was a hard decision to make. I carefully considered the problem that
you point out. Both options were bad, from my point of view, and both
helped/harmed clients in equal but different ways. So I did my best to
choose the "easiest" option, from a maintainer's perspective.