Split KWin for Wayland and X11 at build level
Open, LowPublic

Description

Goals:

  • Allow building a full KWin as Wayland server package without any X dependency.
  • Allow building a full KWin as X11 window manager package without any Wayland dependency.
  • Make XWayland optional to KWin Wayland at build time.

Plan:

  • Split out Wayland only parts in separate lib: D24199 ...
  • Split out X only parts in other lib.
  • Until there are only common parts in the lib we had before.
  • Then see if we can refactor these common parts such that only the two separate libs remain, for example by creating an XWayland lib/plugin/something.
romangg created this task.Oct 17 2019, 12:43 PM
romangg triaged this task as Low priority.
romangg updated the task description. (Show Details)

The only parts we can move now are the parts that already really well encapsulated.

I am all for splitting up some of the other parts where we have messy mixtures of both into encapsulated wayland and X versions but I don't see how making a lib first helps achieve anything or even helps make the process easier.

Let's go the other way around: what's the preferred end result? And how would you try to achieve this without some internal libraries?

Having different libs has the advantage that we have a clear indication on when the messy mixture is not messy anymore for certain parts, i.e. when WaylandPartA really does not depend anymore on X11PartB we can put it in the Wayland-only lib. If all the libraries are needed anymore in the end is a different question but can then be reviewed again.

apol added a subscriber: apol.Oct 17 2019, 3:25 PM

A way of dealing with this without creating normal libraries would be to use add_library(OBJECT)

You can learn about them here: https://cmake.org/cmake/help/v3.8/command/add_library.html?highlight=i#object-libraries

zzag added a subscriber: zzag.EditedOct 22 2019, 11:40 AM

While I'm all for building KWin w/o X11 stuff, I think it's way too early to split kwin code into different libraries. X11 is used in many places. We need to take care of that first. Once we have distinct line between X11 stuff, Wayland stuff, and stuff that doesn't use any of those two, we can proceed with discussing this task.

In T11886#204906, @apol wrote:

A way of dealing with this without creating normal libraries would be to use add_library(OBJECT)

You can learn about them here: https://cmake.org/cmake/help/v3.8/command/add_library.html?highlight=i#object-libraries

Iirc object libraries get compiled into the executables. This would mean that every autotest gets all of the source files compiled into, which increases size of these binaries manifold and possibly compile time.

In T11886#205370, @zzag wrote:

While I'm all for building KWin w/o X11 stuff, I think it's way too early to split kwin code into different libraries. X11 is used in many places. We need to take care of that first. Once we have distinct line between X11 stuff, Wayland stuff, and stuff that doesn't use any of those two, we can proceed with discussing this task.

The idea of this task is to define in code with what we want to end out with and then incrementally approach this result by splitting out X11/Wayland only code over time.