On Mon, Mar 20, 2017 at 4:47 PM, Thomas Kluyver <tak...@gmail.com> wrote:
> On 20 March 2017 at 15:13, René Dudfield <ren...@gmail.com> 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.
