Re: [pygame] pygame with SDL2 proposal

On Mon, Mar 20, 2017 at 4:47 PM, Thomas Kluyver <takowl@xxxxxxxxx> wrote:

On 20 March 2017 at 15:13, René Dudfield <renesd@xxxxxxxxx> wrote:
The big advantage is that it is a much smaller change than something new.
smaller changes reducing risk
the smaller amount of resources needed to get to SDL2
I think we're talking at cross purposes, because what I'm arguing against (supporting SDL 1 and 2 at the same time) requires *more* resources, not less. You have to expend the effort to make SDL 2 work either way, but with your proposal, you must also expend extra effort to ensure that SDL 1 still works, and still more effort to build the mechanisms to switch between them at build time.

Looking into how much config we will need to change, and exploring why I think supporting SDL1 is useful further...

First details on config.

For each platform our config scripts will have the SDL2 stuff added. config_unix.py for example.

if sdl2:
    ...
    DependencyProg('SDL', 'SDL_CONFIG', 'sdl2-config', '2.0', ['sdl']),
else:
    ...
    DependencyProg('SDL', 'SDL_CONFIG', 'sdl-config', '1.2', ['sdl']),

The current build should require no more effort to build pygame with SDL1 as it is now. (I guess that sounds obvious) What I mean is that keeping it compiling with SDL1 doesn't really add that much extra work. Whilst there is a small maintenance cost for keeping the SDL1 code there, I think we need to pay it until we finish the transition (see end of email).

The extra work goes into making SDL2 builds work. Concretely, it looks like the config file include paths, and library paths are different. But also building the dependencies on windows will be a major piece of work, since the current windows build chain is not supported by SDL2 (or maybe that's changed).

For dependency building we can have two scripts to build the different ones. On manylinux we add the extra SDL2 based dependencies to the docker builds, so we can build both with one image. I think that's not so hard.

For travis linux, and launchpad, we add a few more apt packages for sdl2.
For travis osx, we add a few more homebrew packages for sdl2.

Windows... dependencies all need to be redone for SDL2. Hopefully we can lean on the SDL2 binaries here more.

As you say, getting people to upgrade at once to SDL2 on various distros will not really be possible. Since we can't, that means SDL1 still needs to be supported for the time being. If people can't use SDL1 for the moment with pygame, then we will be in a situation where two branches are needed. Rather than that, it seems simpler for me with a single code base for SDL1 and SDL2.

SDL1 using people can keep with that for the time being

My proposal is that people who need to stick with SDL 1 will install pygame <2. We can either declare it finished and let people rely on the last working release, or make occasional 1.9.x releases to fix critical bugs. Either way, that seems less effort that trying to carry SDL 1 support forwards with us as we support SDL 2. Pygame 1.9.3 works well enough for lots of games, and I'm fine with saying that we're leaving SDL 1 support there.

I think doing a new SDL2 based build will potentially take quite some time on all platforms to finish. In that time in the middle, where it's not ready yet, I think it'd be easier to keep the same code base and infrastructure(For those fixes).

Additionally, because some platforms are going to be easier to port to SDL2 than others, being able to release a new pygame with either depending on if the platform has SDL2 or is easy to port to SDL2 will not hold up all the platforms. So if windows is much harder, then we could still potentially build new releases with our existing toolchain and SDL1. And the windows port is going to be much more time consuming, than say linux. It's a better place to be in not having to hold everything up whilst we wait on all platforms to be finished.

And that's the most important reason for keeping SDL1 for now: it allows us to keep having releases on some platforms whilst the work continues, and not have to maintain two sets of infrastructure.