Linux Support

[AstraLuma]

Add Linux wheels.

The primary problem with this is that there's no official binaries are available, so they need to be compiled (probably with the help of manylinux).

[AstraLuma]

Hi from PPB.

Yes, I'd be happy to help with this.

The way I figure is that you should move to building platform wheels in CI. Especially linux, so you have repeatable, isolated builds of SDL built on manylinux's work of distro support.

Of course, I have Opinions About CI, which don't include using travis.

[a-hurst]

Hi @astronouth7303, glad someone's willing to collaborate on this! I'm very thankful for any help you provide in getting this working. I'm definitely in agreement about building the binaries via CI + manylinux, I think anything else would quickly become an unmaintainable mess.

Based on the research I've already done into this, I think the path of least resistance is going to be getting this working using the newer manylinux2013 wheels, which are based on CentOS 7 instead of manylinux's CentOS 5 and have far more of SDL2's optional Linux dependencies as an easy package installation (you'd need to build most of them from source on CentOS 5). The main drawback of the manylinux2013 wheels is that they've dropped Python 2.7 support, but since it's EOL anyway and using an older manylinux wheel would make building the binaries a lot more work, I think it's worth the trade-off.

Also, since I want to make the wheels as flexible as possible, I'd ideally want to install the most optional dependencies possible prior to the build. See this excerpt from the official SDL2 wiki:

SDL on Unix should only link against the C runtime (glibc). Every thing else it needs will be dynamically loaded at runtime: X11, ALSA, d-bus, etc. This means it is possible to build an SDL that has support for all sorts of targets built in, and it will examine the system at runtime to decide what should be used (for example, if Xlib isn't available, it might try to load Wayland support, etc). In that respect, if you plan to ship the SDL binary that you build, it is to your benefit to make sure your system has development headers for as many targets as possible, regardless of what you plan to personally use, so your final library is as robust as possible.

I've got a text file somewhere with most of the names of the possible dependencies and their "yum install" names for CentOS 7, so hopefully that's not too much of a pain.

As for CI and Travis: if there's something else you'd prefer to use for the sake of this eventual pull request, and it doesn't cost me any money to sign up, and doesn't use a wildly unorthodox .yml structure, I'm all for it.

[AstraLuma]

Opinion Summary: Cirrus CI is currently my favorite. Also supports Windows and Mac, so you could do all your builds on CI.

Glad to know that SDL doesn't have hard dependencies. I think there's some policy to be had about what should be expected to be installed--xlib can be safely assumed to be installed if it's a desktop but maybe not every codec library.

[a-hurst]

The parts of SDL2 that need codec libraries are mostly the secondary SDL2_mixer and SDL2_image libraries, which bundle libraries like libFLAC, libVorbis, and libPNG along with them in the official Windows/Mac binaries. SDL2_ttf also requires FreeType to work. Those will need to be built and bundled along with.

By the way, here's the list of optional SDL2 dependencies for CentOS 7 I was able to dig up. Technically I think all we need for SDL2 to build in support for them are the development headers, but installing everything with a package manager will probably end up easier than trying to gather those otherwise:

yum install alsa-lib-devel pulseaudio-libs-devel nas-devel libX11-devel \   
    libXext-devel libXrandr-devel libXcursor-devel libXi-devel libXinerama-devel \
    libXxf86vm-devel libXScrnSaver-devel esound-devel dbus-devel systemd-devel \
    ibus-devel fcitx-devel libsamplerate-devel wayland-devel libxkbcommon-devel \
    wayland-protocols-devel jack-audio-connection-kit-devel arts-devel \
    mesa-libGL-devel mesa-libEGL-devel mesa-libGLES-devel libdrm-devel \
    mesa-libgbm-devel libusb-devel vulkan-devel tslib-devel


Extra Repos: 
- Nux Dextop x86_64 (for nas-devel)

not found:
- libgl1
- sndio

I also have something resembling a working SDL2 + addon library build script written in Python, based on the script I wrote for installing SDL2 on Linux for pysdl2's CI setup, that will hopefully serve as a reasonable basis for getting these binaries built, it's on a different machine in a VM so I'll dig that up later. The main part I haven't looked into at all and have little idea on how to tackle is the use of the manylinux docker image to build the binaries: I've only used it indirectly through cibuildwheel before, but since we're trying to build regular .so binaries to bundle in a wheel (and not a binary wheel directly, since that's only for Python projects with C code) we'd need to use the image as a build environment in a non-standard manner.

[AstraLuma]

Using manylinux_2014 is pretty straight forward. It just has a pile of system pythons installed at /opt/python. The real value of it is that it's a minimal old-ish system. Any libraries not in the image, you should consider shipping.

My thought is to bend these rules slightly on the assumption that you're not using SDL in a headless environment. So we can assume a reasonable set of installed libraries that are effectively essential for desktop systems (stuff like xlib, libwayland, libfreetype, probably some others), and let SDL do its thing if they're missing. This list should also be documented for use-cases that do involve headless environments (eg CI).

[AstraLuma]

With the Raspberry Pi 400, we should make sure pi-compatible ARM builds are included in this.

[a-hurst]

Closing via #4.