On 16 March 2017 at 12:40, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Tue, 21 Feb 2017 16:14:28 +0000
> Emil Velikov <emil.l.veli...@gmail.com> wrote:
>
>> From: Emil Velikov <emil.veli...@collabora.com>
>>
>> Currently both of libwayland-{client,server} export the same util
>> (amongst other) symbols.
>>
>> Although not crucial this is something which should be avoided where
>> possible.
>>
>> As such let's move the library to a shared one and introduce a static
>> one for the purposes of wayland-scanner.
>>
>> Any old (existing) users of the new libwayland-{client,server} will be
>> safe since the libwayland* libraries will pull the util one and the
>> symbols will be resolved at runtime.
>>
>> Any programs building against the new libraries will have the dependency
>> (both compile and link-wise) resolved automatically by the Requires
>> field of the .pc file.
>>
>> Note: it's not possible to 'hide' the wl_list/wl_array API since it's
>> been part for the ABI (implicitly pulled via the wayland headers) for a
>> while, plus doing so will break KF5 and mpv, at least.
>>
>> v2: Rebase
>>
>> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
>> ---
>>  Makefile.am                          | 18 ++++++++++++------
>>  configure.ac                         |  2 ++
>>  src/wayland-client-uninstalled.pc.in |  1 +
>>  src/wayland-client.pc.in             |  1 +
>>  src/wayland-server-uninstalled.pc.in |  1 +
>>  src/wayland-server.pc.in             |  1 +
>>  src/wayland-util-uninstalled.pc.in   |  8 ++++++++
>>  src/wayland-util.pc.in               | 12 ++++++++++++
>>  8 files changed, 38 insertions(+), 6 deletions(-)
>>  create mode 100644 src/wayland-util-uninstalled.pc.in
>>  create mode 100644 src/wayland-util.pc.in
>
> Hi,
>
> since I have so much trouble making my mind on this patch, how about a
> silly counter-proposal?
>
> Let's squash libwayland-server.so and libwayland-client.so into a
> single libwayland.so.
>
> That would take care of the duplicate exported symbols issue not just
> for the util functions, but also for the exported variables produced by
> wayland-scanner. Since we have many programs (libEGL!) that necessarily
> already link to both, there cannot be problems from linking to
> everything always.
>
> We would still need to install dummy libwayland-server.so and
> libwayland-client.so just for pulling in libwayland.so, but that's no
> worse than Emil's proposition.
>
> Whether we have the existing .pc files telling to link to server/client
> or just libwayland.so would be up for debate. I'm not suggesting to
> merge the .pc files.
>
> libwayland-server.so and libwayland-client.so have exactly the same set
> of dependencies.
>
> Any downsides to this approach vs. doing nothing vs. Emil's
> libwayland-{client,server,util}.so?
>
The following come to mind:
 - any downsides of libwayland-util.so [that I can think of] also
exist in the libwayland.so proposal
 - managing the compat server/client DSO in any build system will be a pain
 - distributions and third party builders will "come up" with their
own way to manage ^^
I've seen it with the Mesa mega-drivers and you _really_ don't want to
spend same/similar about of time hand-holding people.

With all due respect the whole thing has become a massive bikeshed,
admittedly with some 'help' of my end as well.
The more we continue the less inclined I'm at fixing other issues in Wayland ...

As a closing thought - I would really appreciate a list of concrete
issues or "actions" where I could work against.
Pretty please ?

Thanks
Emil
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to