[Mesa-stable] [Mesa-dev] [PATCH 1/5] wayland-egl: allow shipping the library or not
Emil Velikov
emil.l.velikov at gmail.com
Tue Jun 5 18:15:52 UTC 2018
On 5 June 2018 at 18:13, Matt Turner <mattst88 at gmail.com> wrote:
> On Tue, Jun 5, 2018 at 8:24 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 5 June 2018 at 16:07, Eric Engestrom <eric.engestrom at intel.com> wrote:
>>> On Tuesday, 2018-06-05 15:14:30 +0100, Emil Velikov wrote:
>>>> From: Emil Velikov <emil.velikov at collabora.com>
>>>>
>>>> Recently the wayland-egl library and pkg-config file were moved to the
>>>> Wayland repository. With that a strange conflict came to be - which one
>>>> should be used and when.
>>>>
>>>> The long term goal is to remove the Mesa copies, but with this patch we
>>>> allow builders to explicitly select if they want it.
>>>>
>>>> Note: since the header (wayland-egl-backend.h) is now used by C++
>>>> people, s/private/driver_private/ was applied.
>>>>
>>>> Cc: Eric Engestrom <eric.engestrom at intel.com>
>>>> CC: 18.0 18.1 <mesa-stable at freedesktop.org>
>>>> Signed-off-by: Emil Velikov <emil.velikov at collabora.com>
>>>> ---
>>>> configure.ac | 17 +++++++++++++++++
>>>> meson.build | 12 ++++++++++++
>>>> meson_options.txt | 6 ++++++
>>>> src/Makefile.am | 2 ++
>>>> src/egl/Makefile.am | 1 +
>>>> src/egl/drivers/dri2/platform_wayland.c | 12 ++++++++++++
>>>> src/egl/meson.build | 2 +-
>>>> src/meson.build | 2 +-
>>>> 8 files changed, 52 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/configure.ac b/configure.ac
>>>> index 02dca4547c8..5ea52242bd1 100644
>>>> --- a/configure.ac
>>>> +++ b/configure.ac
>>>> @@ -89,6 +89,7 @@ LIBOMXIL_BELLAGIO_REQUIRED=0.0
>>>> LIBOMXIL_TIZONIA_REQUIRED=0.10.0
>>>> LIBVA_REQUIRED=0.39.0
>>>> VDPAU_REQUIRED=1.1
>>>> +# TODO: Bump to 1.15 -> the first version that ships wayland-egl-backend
>>>> WAYLAND_REQUIRED=1.11
>>>> WAYLAND_PROTOCOLS_REQUIRED=1.8
>>>> XCB_REQUIRED=1.9.3
>>>> @@ -1766,6 +1767,18 @@ if test "x$enable_glx_read_only_text" = xyes; then
>>>> DEFINES="$DEFINES -DGLX_X86_READONLY_TEXT"
>>>> fi
>>>>
>>>> +dnl
>>>> +dnl TEMPORARY: mostly for stable releases
>>>> +dnl
>>>> +dnl It will allow easier management as the wayland-egl library was
>>>> +dnl moved to the Wayland project
>>>> +dnl
>>>> +AC_ARG_ENABLE(bundled-wayland-egl,
>>>> + [AS_HELP_STRING([--disable-bundled-wayland-egl],
>>>> + [disable shipping of the wayland-egl library and pkg-config file @<:@default=enabled@:>@])],
>>>> + [enable_wayland_egl=$enableval], [enable_wayland_egl=yes])
>>>> +AM_CONDITIONAL(BUILD_WAYLAND_EGL, test "x$enable_wayland_egl" = xyes)
>>>
>>> I'm not sure I see the benefit of your variant of adding all the
>>> complexity of a new option and immediately making it an error to use it.
>>> Could you explain your logic?
>>>
>> In all fairness, it should have been introduced when wayland-egl was
>> proposed for Wayland inclusion.
>> Back then I was under the naive assumption that, distribution maintainers will:
>> - read mesa-maintainers@ or the wayland release notes
>> - will know how to address the multiple copies of libwayland-egl.so
>>
>> Since then a distribution (wish shall remain unnamed), kind of
>> foobar'd both of the above.
>
> This is not a productive way to talk to people, and as a distro
> maintainer that has been aware of the change and has been asking you
> specifically for guidance for months it really rubs me the wrong way.
>
As you may have noticed I took a ~month away from Mesa, since despite
by best of intentions I manage to get under your skin :-(
> Neither your email to mesa-maintainers@ nor the Wayland release notes
> told distros what to do... because there wasn't anything that could be
> done since you never finished the Mesa bits. As for knowing how to
> address multiple copies of a library: we do. We delete the one we
> don't need and we ask upstream to sort their crap out.
>
Offline I've asked a couple of distribution packagers, admittedly not
the ones handling mesa/wayland:
"Do you have a way of dealing when library X moves from project A to B?"
The answer was a categorical, "yes" although the specifics varied.
One preferred to use B as early as possible, while another A for as
long as possible.
Both suggested against upstream telling them which route to opt for.
Now you know why the "will be removed" message was given without
explicit instructions.
The series sent earlier is effectively Eric's work with his authorship
preserved. There are some important fixes as mentioned earlier.
HTH
Emil
More information about the mesa-stable
mailing list