[RFC wayland] wayland-server: Finally remove deprecated struct wl_buffer definition

[Emil Velikov]

On 16 February 2018 at 18:24, Derek Foreman <derekf at osg.samsung.com> wrote:
> On 2018-02-16 11:18 AM, Emil Velikov wrote:
>>
>> On 16 February 2018 at 16:54, Derek Foreman <derekf at osg.samsung.com>
>> wrote:
>>>
>>> commit d94a8722cb29d8b897672be66ff3c9ff79eab6fe
>>> warned this was coming, back in 2013.
>>>
>>> I've seen libraries that have wayland client and server using functions
>>> in the same file.  Since struct wl_buffer still exists as an opaque
>>> entity in client code, the vestigial deprecated wl_buffer from the
>>> server include will generate warnings when not building with
>>> WL_HIDE_DEPRECATED.
>>>
>>> Signed-off-by: Derek Foreman <derekf at osg.samsung.com>
>>> ---
>>>
>>> Is there anyone out there this will hurt?
>>>
>>> I'd like to at least see WL_DEPRECATED dropped from wl_buffer,
>>> since it causes annoying build warnings when mixing client/server
>>> code in the same files - even when not using the non-opaque
>>> struct wl_buffer.
>>>
>> There are a few Mesa patches related this:
>>
>> be52bd17ebf114e7ad16a6d9d0135cdbb0723cd0 - 17.3.0+
>
>
> Not really related that I can see? I didn't touch struct wl_resource at
> all...
>
>> fa6b9be22c7a85a8766a31411caafdbe1694d7dc - 17.3.0+
>
>
> Can't see how I could cause a problem here?  WL_HIDE_DEPRECATED has always
> hidden struct wl_buffer, so compilation with WL_HIDE_DEPRECATED should be
> exactly as before.
>
>> 66ebdfbd44cb62c58a7711fb72566f07d801809a - 17.2.3+ (stable port), 17.3.0+
>
>
> We also provide a struct wl_buffer forward decl in wayland-server-protocol.h
> which is (autogenerated and) included from wayland-server.h
>
> Presumably that patch was written for people not including wayland-server.h
> at all?  They shouldn't have much trouble with eliding the full struct
> definition they weren't including.
>
The list was pulled based on a quick grep. I haven't explicitly
checked that each case is 100% applicable.

>>
>> Can you please double-check that Mesa continues to build fine, wit and
>> w/o the above patches?
>
>
> I've test built mesa from the git 17.2 and 17.3 branches, as well as git
> master, and they seem ok...  Building mesa is a bit of a dark art though, so
> hopefully no configure options changed, and I was building everything I
> thought I was.
>
> If you want me to test build any specific SHAs, give me a list...  I've got
> a reasonably fast computer here.
>
Just pull some tarballs [1] before + after the releases mentioned and
ensure you have the following set at configure time.
--enable-egl --enable-gbm --with-egl-platform=drm

Don't be shy to make enlightening suggestions making it less of a dark art ;-)

Thanks
Emil

[1] https://mesa.freedesktop.org/archive/