X11 and Wayland in one build

[yol]

It would be desirable to have support for X11 and Wayland in one build so distributions do not need to ship two packages.

Not yet decided if this is doable and worth the effort, Kodi seems coded around the assumption that only one windowing system is in the build, determined at compile time and not at runtime.

[gonciarz]

Hi, having dual support in one package leads to having Wayland and X11 dependencies at the same time. I think that end users wants to get rid of X11.

[yol]

They may want to eventually, but we need some solution for the transition period. There will be no hard switch and X11 will be around for a long time. The possibilities I currently see for distributions (that offer Wayland at all) are:

1. Ship only kodi-x11 because it works on X11 and Wayland (via Xwayland). Obviously not what we want.
2. Ship only kodi-wayland. Users that don't want to (e.g. due to missing features) or can't (e.g. because of NVIDIA binary drivers) use Wayland will be unhappy.
3. Ship both kodi-x11 and kodi-wayland as separate packages. Confusing to the end user and harder to maintain.
4. Ship both kodi-x11 and kodi-wayland in one package, possibly with a wrapper script that starts one or the other based on what is running. Seems like a sensible option to me, but is still a maintenance burden.
5. Ship one kodi package/build that supports both X11 and Wayland and decides what to use on startup. Probably best for distributors - it's also what most other packages seem to do - but unfortunately a lot of work on the kodi side.

Mind you, most toolkits etc. also require both X11 and Wayland on major distributions at the moment, see here for example. So for end users of desktop distributions, going without X11 libraries will (for better or worse) likely not be an option for the foreseeable future, no matter what we decide here.

[gonciarz]

I'm not the expert in the area, but the 5th option seems the most reasonable for transition period.
But whatever you decide you may take a look at ArchLinux package for Kodi and Debian's one:
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/kodi
https://anonscm.debian.org/cgit/pkg-multimedia/kodi.git/tree/debian/control
Each distribution has it's own flavours, but they already produce several artefacts within one build (one source package, several binary packages).
Regarding dependencies, there are are build ones and runtime, so even though you require x11 dependencies during build (kodi-x11 and kodi-wayland) the kodi-wayland package may not require it in runtime.

[FernetMenta]

As @pkerling mentioned, 5th option is a long way to go. Kodi's GUI needs to be separated from the main thread. Then the application can run headless or load an approprite UI implementation.

[yol]

@FernetMenta I don't think we necessarily need headless support or dynamic loading of UI implementations. It should be sufficient to be able to build multiple platform implementations into one binary statically. This can be achieved by making the global g_Windowing not equal to the concrete class but only downcasted to the CWinSystemBase interface. It's still some work because the code assumes that g_Windowing is the concrete class, but it could be manageable.

[FernetMenta]

I meant that those kind of changes have to be done in a broader context, not just with platform scope. Headless suppport is on the list of wished for quite a while. This feature here will be a side product.

[yol]

OK so this will not happen as part of the GSoC work since it just too much work if done correctly to be finished in the remaining time. I'm leaving this open as future addition. Packagers can adopt option 3 or 4 in the meantime.