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

[Emil Velikov]

On 16 February 2018 at 20:22, Derek Foreman <derekf at osg.samsung.com> wrote:
> On 2018-02-16 12:58 PM, Emil Velikov wrote:
>>
>> 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
>> ;-)
>
>
> Well, I suppose if it wasn't a dark art, you'd have given me functional
> build instructions? ;-)
>
> --with-egl-platform is wrong, it's --with-egl-platforms for most releases,
> but apparently --with-platforms for some others (though only generating a
> warning).
>
Woohoo, I'm a master of the dark arts (typos). And yes, I made sure
that EGL option still works, while deprecating it ;-)

> Also, apparently R300 is enabled by default, but llvm isn't for most (all?)
> releases, yet llvm is required for R300... so I added
> --with-gallium-drivers=swrast (I suppose ='' would've been fine too? shrug)
> so configure would succeed.
>
> I've also added --with-with-dri-drivers=i965 to reduce build time, since
> that's what I usually do, I don't think any of those additional drivers
> should be doing anything wl_buffery
>
> Some releases apparently require --disable-glx when configured without x11
> in --with-egl-platforms but some didn't have a problem with it.
>
> I've built 17.0.0, 17.0.7, 17.1.0, 17.1.10, 17.2.0, 17.2.8, 17.3.0, 17.3.4,
> 18.0.0-rc4.
>
> No build failures, no log chatter regarding wl_buffer
>
> I have not installed all of these versions and tested functionality, but due
> to the nature of the change I can't imagine that being necessary?
>
Sounds great IMHO.

Meanwhile I've done some grepping on local checkouts. The following
are fine (git master~ish) to use opaque wl_buffer:

* xserver
* kodi
* ffmpeg
* mpv
* libva
* libva intel-driver
* mesa

* gnome - shell, mutter, clutter
* kde - kwin, plasma, plasma-workspace
* qt - base, 3d, multimedia

Above said, the patch is
Acked-by: Emil Velikov <emil.velikov at collabora.com>

If one wants to be _really_ pedantic they can rebuild their favourite distro.
Seems like an overkill, though.

Thanks
Emil