[PATCH wayland v2 3/4] wayland-util: build/ship as separate shared library

Fri Mar 17 11:10:30 UTC 2017

On Thu, 16 Mar 2017 15:32:46 +0000
Emil Velikov <emil.l.velikov at gmail.com> wrote:

> On 16 March 2017 at 12:40, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > On Tue, 21 Feb 2017 16:14:28 +0000
> > Emil Velikov <emil.l.velikov at gmail.com> wrote:
> >  
> >> From: Emil Velikov <emil.velikov at 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.velikov at 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

The number of .so files? Yes.

>  - managing the compat server/client DSO in any build system will be a pain

How so? Whose build system?

User projects do not necessarily need any changes, ever.

Wayland's build we need to set up once.

So, again very much the same as your proposal.

>  - distributions and third party builders will "come up" with their
> own way to manage ^^

What might they want to manage there?

> 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.

How is this in any way similar to anything in Mesa, particlarly the
mega-drivers? Not that I would even know what the problems there are.

Our two separate libs are tiny, there are no disk space or RAM savings
from trying to leave one out. One always needs both on your system,
there is no way to need only one. In many cases, one also loads both
anyway, regardless whether the program is a client or a server, due to
libEGL.

Didn't mega-drivers use some sym- or hardlinking tricks? I didn't
imagine we'd need such, we'd just have libwayland-server.so and
libwayland-client.so like before, except all they do is depend on
libwayland.so which the runtime linker will load automatically. I
suppose they could be just linker scripts in .so files, but proper DSOs
are probably more portable.

If there is any similarity left, could you explain the issues you have
seen?

However, there is one thing I noticed that might make the squashing a
little awkward: libwayland-client.so and libwayland-server.so are
versioned in different numbers. I don't really know if that's an actual
problem, since both have been declared backwards ABI-compatible for
years and the dummy .so files would still exist with their respective
versionings.

> 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 ...

Sorry about that.

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

I have none. I do not have enough knowledge to form an opinion or make
a decision to accept/reject. If I can't give an authoritative Acked-by,
and no-one of the well-known expert developers did either, then I
cannot merge a change that definitely (IMO) needs seconding.

Basically I have been waiting for someone besides you who would also
know about this topic to give their opinion on the proposal(s), because
I am disqualified. I was hoping my replies would have raised more
interest by showing I take the suggestion seriously rather than just
ignore it to death, but it didn't happen.

Btw. the squashing started as a half-joke, since we seemed to be going
nowhere, to try and provoke more participation or points of view, but
the more I thought about squashing, the more sense it started to make.
And it's a second failed attempt to draw more attention to this
question. I got the idea for squashing from systemd libraries, not Mesa.

Indeed, that's what I need: Reviewed-by's and Acked-by's from people
with proper reputation.

Just like for any patch really, the strength of reviews needs to
reflect the impact of the patch.

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170317/eebbe5fd/attachment.sig>