libsdl-org
Idea: Custom platform plugins
There is a case when people like me, attempting to make custom platforms support that aren't officially supported by SDL (such as legacy platforms like Mac OS X Tiger, or the homebrew Nintendo Switch support). That leads a fragmentation into different editions of SDL2: for these platforms the exclusively modded SDL2 version is needed. There is a problem that creators of these ports do need to maintain them and merge official updates sometimes (at least for every stable release). However, the homebrew Nintendo Switch version is an example that stuck on SDL 2.0.14 and wasn't updated for a while (and they didn't replied to my pull-requests that fixes touchscreen and audio related bugs).
So, I got an idea that could help to resolve this case:
- SDL itself needs a lesser number of built-in modules to maintain (just, to support mainstream platforms like UNIX-like systems, Windows, macOS, Android, iOS, etc.)
- Each custom platform can be maintained independently from the mainstream SDL (you aren't required to keep ABI compatibility to these modules, as these modules must follow each update of SDL)
- In addition, if you maintain private things like official Nintendo Switch SDK support (which is providen separately and closely because of NDA), you will don't need to maintain separated SDL version to support these platforms. You'll just have to provide this hidden module to granted developers, and they will be able to use mainstream SDL to use the desired platform.
I think, these custom platform modules could be made as static libraries that can be linked to SDL2 itself (the use of each plugin could be specified at SDL2's configure to tell it use the custom platform module instead of default things).
P.S. I think, it's possible to implement this concept with a minimal effort, just re-using the current infrastructure:
- for each sub-system, provide the bunch of "custom" entry points if needed
- when developer wants to include the custom implementation of the sub-system (for example, audio, video, timers, threads, joysticks, etc.), they should specify that during the build of SDL2 to link their custom module that follows the API.
- these modules should be linked to SDL2 itself as they implements SDL2's sub-systems, users shouldn't find a difference that they use a custom platform plugin instead of the built-in platform module.
That's kind of how it already works, there just isn't a good way to dynamically register the backend drivers or integrate them into the build system.
As an idea can be passed via a custom CMake sub-directory (the path to it should be linked as an argument of SDL's CMake build). And, there is a skeleton plugin is needed as an example for others who wants to implement the custom platform. That module must declare which custom sub-modules it implements to let SDL's main build handle them instead of attempting to seek among built-in modules.
I think if we do this, we should convert existing platform code to use it. If all platforms are implemented that way, it'll be easy to see the pain points when adding a new one.
Also, keep a note that certain parts were can be shared among other platforms like UNIX/POSIX parts are available on a majority of platforms. But, there are two ways:
- have that shared part that can be optionally re-used by other modules
- let every platform counterpart have its own copy of these modules, especially if it has variety of tweaks like different API availability, etc.
- these share parts can stay at own "common" module that will be included by each platform plugin separately.
And ye, if you going to keen default plugins, just let them auto-plugged by the main SDL CMake (if no custom platform module path specified on configure).
@Wohlstand
I've got a PoC at https://github.com/madebr/SDL/tree/cmake-support-for-external-modules.
It introduces a few hook points which platforms need to implement.
See the cmake/sdl_platforms dir for all platforms.
For nx, you need define these functions in a file, and passing it to SDL's cmake script with -DSDL_CMAKE_PLATFORM_FILE=/path/to/nx.cmake.
This is SDL3 only, so you'd need to port your SDL port :wink:
Ye, this idea is totally for SDL3, because it's a major change, and it's a good moment to implement this idea during SDL3 inital development. :)
btw, speaking about custom platforms, I even wanted to make a shot to make the Windows 98 support for my own experiments (I wanted to make a game run on a very old computer just for a sport interest).
I didn't touch any C code in my poc, it is all about cmake handling.
There currently is not a mechanism to add a new item to the various bootstrap arrays (like this one for audio). Also, dynapi is enabled by default for unknown platforms, and cannot be disabled by an external definition.
Glancing over DevkitPro's switch SDL2 port, I think these are the major missing things.
btw, I found you decited to bump the CMake version to 3.16. Why did you that? Requirement of new CMake kills the ability to build the SDL3 using system CMake installations that usually has early 3.x versions. I agree that it's possible to manually build the latest CMake from the source or download prebuilt packages of latest CMake to launch on the target thing. But, this makes a complication for users who want to bring the latest SDL3 on their legacy thing.
btw, I found you decited to bump the CMake version to 3.16. Why did you that? Requirement of new CMake kills the ability to build the SDL3 using system CMake installations that usually has early 3.x versions. I agree that it's possible to manually build the latest CMake from the source or download prebuilt packages of latest CMake to launch on the target thing. But, this makes a complication for users who want to bring the latest SDL3 on their legacy thing.
What cmake platforms don't have an updated cmake port? We have https://github.com/libsdl-org/SDL/issues/7079 for discussing the new minimum required cmake version. If this (legacy) platform has a cross compiler, it's always possible to build SDL on a modern build system.
Speaking about CMake, mostly I had to install something like 3.2.x on old Ubuntus via custom ways. Even Mac OS X 10.4 Tiger with the Tigerbrew has a newer CMake that natively works on machine itself (I don't remind exact version, but it's one of very new. I know that because I made my own attempt to bring the SDL2 to such old Mac host with the PowerPC processor).
I don't mind if there is a SERIOUS reason to bump the minimum CMake version to something newer. For example, you want to get rid a lot of crapcode and simplify internalities using new features, etc. At my CIs where I build my projects for old systems, I use downloaded CMake packages of newer CMake thing as these platforms (such as Ubuntu 16.x) lack the accessibility to install newer CMake via packages. Custom build toolchains even they target to very ancient platforms has much more chances to get the latest CMake version, and I totally agree with that.
The most important new feature I can use is target_link_options, which is 3.13+.
Since previous year, the satellite libraries also require 3.16, to which no objections came.
Also keep in mind the 3.16 minimum version will (probably) not be changed during the lifetime of SDL3.
I had used the "target_link_libraries()" at older CMake versions to pass options, and that seems worked. I used that to force the static/shared library search for individual libraries (-Wl,*** thing I mean).