sdl2-compat binary releases

[icculus]

Are we doing binaries for sdl2-compat? Someone asked me on Twitter, and @madebr asked me to add an issue so we can come back to it later.

[madebr]

What do we want in the release?

• source archive
• MSVC x86 and x64 binaries (no VC-devel or mingw-devel)
• macos dmg

If a macos dmg is desired, then a Xcode project would be nice to have.

[slouken]

For Windows we want the same archives that we have for SDL2, with the addition of SDL3.dll. macOS is a little trickier, I'll have to think about that.

[slouken]

Or maybe we do just want drop in DLLs, and someone can just grab the SDL2 development archives if they want those. I was initially thinking that we'd want an sdl2-compat release to be a drop in replacement for an SDL2 release.

@icculus, thoughts?

[icculus]

If it works like sdl12-compat, eventually Linux distros will literally ship it as their full SDL2 package, but for what we give out, I suspect most people only care about getting a DLL.

[slouken]

Then I think for now, just source and win32 binaries is all we need.

[smcv]

If it works like sdl12-compat, eventually Linux distros will literally ship it as their full SDL2 package

That's my long-term intention in Debian, certainly (most likely not in Debian 13, perhaps Debian 14) - but for that, we only need a source release (tarball or git tag) and the distro will handle the rest.

[icculus]

I think first official release would be on the day SDL 3.2.0 ships.

[smcv]

As a distro packager, I would like to be able to package a preview release that has "gone through the motions" of building an official release (like I did for a not-quite-3.1.3 source release of SDL3 provided by @slouken), before the first official advertised-as-stable release, so that if there is a problem, I can tell you about it before it's too late to fix. I can upload the resulting packages to a location that is not intended to be stable or suitable for typical users: in my case that's Debian experimental, which is specifically not expected to be release-quality or stable, and I would hope that packagers with an equivalent role in other distros have something similar that they can use.

At the moment I'm building from git snapshots, but if the source distribution doesn't have the same content as git-archive output, that might result in needing packaging changes or even upstream fixes.

For example if we're generating a VERSION.txt and/or SDL_revision.h to store the version/revision identification in the tarball (see also https://github.com/libsdl-org/SDL/issues/11108), we'll want an opportunity to test that before shipping a stable release.

[slouken]

@madebr, can we put together a preview release with source archive and win32 binaries?

[madebr]

@madebr, can we put together a preview release with source archive and win32 binaries?

Yes we can, I'm still going around all SDL satellite projects adding support for the same release procedure as you used for SDL3 3.1.3. I've done all of SDL2 (except SDL2_net), and am now doing SDL3 (the dmg of SDL3_image is still broken for cmake, and all other satellite libraries are untouched). Then I'll turn my attention to sdl2-compat. I hope to finish this in the course of this week.

[slouken]

Great, thanks!

Let me know when SDL3_image is ready, and I'll make a preview release of that as well.

[madebr]

I hooked up the release scripts with sdl2-compat (in my repo): https://github.com/madebr/sdl2-compat/actions/runs/11258251791

Can you take a look at these Xcode issues? https://github.com/libsdl-org/SDL_mixer/issues/638#issuecomment-2400866770

[slouken]

I hooked up the release scripts with sdl2-compat (in my repo): https://github.com/madebr/sdl2-compat/actions/runs/11258251791

This looks good!

[panreyes]

Thanks @madebr for the binaries!

I just tested the Windows build with one of my recent releases, A Cat & His Boy (an emulated GameBoy game), and it works mostly well just dropping both files, except for an issue related to HiDPI support (my monitor has a 125% scale).

It looks like there is a difference in what I get from SDL2's SDL_GetCurrentDisplayMode and the same function through SDL2 compat.

[slouken]

Thanks @madebr for the binaries!

I just tested the Windows build with one of my recent releases, A Cat & His Boy (an emulated GameBoy game), and it works mostly well just dropping both files, except for an issue related to HiDPI support (my monitor has a 125% scale).

It looks like there is a difference in what I get from SDL2's SDL_GetCurrentDisplayMode and the same function through SDL2 compat.

Can you create an issue and provide what SDL2 returns and what sdl2-compat returns? https://github.com/libsdl-org/sdl2-compat/issues

Thanks!

[panreyes]

Thanks @madebr for the binaries! I just tested the Windows build with one of my recent releases, A Cat & His Boy (an emulated GameBoy game), and it works mostly well just dropping both files, except for an issue related to HiDPI support (my monitor has a 125% scale). It looks like there is a difference in what I get from SDL2's SDL_GetCurrentDisplayMode and the same function through SDL2 compat.

Can you create an issue and provide what SDL2 returns and what sdl2-compat returns? https://github.com/libsdl-org/sdl2-compat/issues

Thanks!

I think I need to look into it further, as all the numbers check:

SDL2:
· SDL_GetCurrentDisplayMode 2560 x 1440
· SDL_GetWindowSize 2560 x 1440
· SDL_GetRendererOutputSize 2560 x 1440
· SDL_RenderGetLogicalSize 1280 x 720

SDL2-compat:
· SDL_GetCurrentDisplayMode 2560 x 1440
· SDL_GetWindowSize 2560 x 1440
· SDL_GetRendererOutputSize 2560 x 1440
· SDL_RenderGetLogicalSize 1280 x 720

But the window is scaled to 125% anyway:

This is the screen setup code of the game engine I'm using: https://github.com/SplinterGU/BennuGD2/blob/06bc85ab9de651074b233ae283aec13b3467abcb/modules/libbggfx/g_video.c#L188

I will try to make a better example to write the issue.

[madebr]

For Windows we want the same archives that we have for SDL2, with the addition of SDL3.dll. macOS is a little trickier, I'll have to think about that.

Do you want SDL3.dll included in the sdl2-compat binary pre-releases?

230 is not adding those currently

[slouken]

Do you want SDL3.dll included in the sdl2-compat binary pre-releases?

That seems like a good idea. That way people can just drop it in and test.

[madebr]

We currently install a lib/pkgconfig/sdl2_compat.pc file. Is that ok? Imho sdl2-compat.pc looks nicer.

Also, if sdl2-compat aims to become a replacement for sdl2, should it also install lib/pkgconfig/sdl2.pc (through a cmake option)? Or it this unnecessary since sdl2_compat has a Provides: section?

[slouken]

We currently install a lib/pkgconfig/sdl2_compat.pc file. Is that ok? Imho sdl2-compat.pc looks nicer.

Also, if sdl2-compat aims to become a replacement for sdl2, should it also install lib/pkgconfig/sdl2.pc (through a cmake option)? Or it this unnecessary since sdl2_compat has a Provides: section?

I think the convention is underscores for pkg-config files, but @smcv may know better.

[smcv]

Actually pkg-config files are more often named with dashes than underscores (for example wayland-client.pc), although there is no particular rule either way. On my Debian 12 system, the only underscores seem to be SDL2_ttf.pc, glesv1_cm.pc and libdrm_{amdgpu,intel,nouveau,radeon}.pc, but there are lots of dashes.

Also, if sdl2-compat aims to become a replacement for sdl2, should it also install lib/pkgconfig/sdl2.pc (through a cmake option)? Or it this unnecessary since sdl2_compat has a Provides: section?

Provides: is a feature of pkgconf, which is a mostly-compatible reimplementation of the interface that originated in the reference (freedesktop.org) pkg-config. Many (but not all!) OS distributions have replaced fd.o pkg-config with pkgconf (for example Debian 11 used fd.o pkg-config but Debian 12 uses pkgconf).

On systems that (might) use the reference/freedesktop.org version of pkg-config, having a Provides: is not enough, and it's necessary to create a symlink sdl2.pc -> sdl2_compat.pc if you want sdl2-compat to "take over" the sdl2 interface. This could either be an option in the upstream build system, or be left for OS distributions to set up for themselves if they want to (it should be an easy thing to do in any reasonable packaging system).

The snapshot of sdl2-compat in Debian experimental currently creates this symlink as part of the packaging for maximum compatibility. Similarly, the version of sdl12-compat available in Debian 12+ has a symlink sdl.pc -> sdl12_compat.pc.

[chadchoi]

I'm using this build by another Github user:

https://github.com/mmozeiko/build-sdl3/releases