Let's wait until 25.08.0 is released, I want to test the build with that. Remind me if I forget.

I didn't add myself to CODEOWNERS because as I see it the SDL1.2 modules don't have a maintainer either, and I don't think I'd be the right person.

That predates the codeoweners file, if you are adding this you have to be the “official” person to maintain it. But others can help anyway through PRs etc. So you should add yourself.

Can you rebase to master?

The x-checker won't work, try using anitya.

Oops, how stupid of me...

However anitya for SDL2_ttf seems to be wrong: https://release-monitoring.org/project/4784/
(SDL2_image does have its separate entry though)

Would it be OK to use git for the sources instead? Like:

    "sources": [
        {
            "type": "git",
            "url": "https://github.com/libsdl-org/SDL_image.git",
            "tag": "release-2.8.8",
            "commit": "c1bf2245b0ba63a25afe2f8574d305feca25af77",
            "x-checker-data": {
                "type": "git",
                "tag-pattern": "^release-(2\\.[\\d.]+)$"
            }
        },

yea that's fine

Would it make sense to switch to CMake + Ninja instead of autoconf since these libraries fully support it as a build system? That should make build recipe a bit cleaner.

Good idea, @tothxa what do you think?

I don't know if this would help, but I already ship SDL2_image with a game I maintain and in my case it builds and works just fine without specifying buildsystem or any other options.
I also suggest adding /lib/cmake to cleanup section.

If you don't specify buildsystem then it uses autotools. Moreover, default behavior is to build static libs which you remove afterwards but could not build them in first place. So defaults work but are inferior to what can be done.

Then you can leave --disable-static in config-opts.

I just thought they wanted to switch to cmake-ninja in order to avoid needing these lines:

        "type": "script",

        "dest-filename": "autogen.sh",
        "commands": [
            "AUTOMAKE=\"automake --foreign\" autoreconf -vfi"

so I wanted to show that simply removing them is enough. Or does cmake-ninja do something better compared to autotools?

autotools is legacy buildsystem, if upstream support cmake/meson it's better to use that.

OK, switched to cmake, thanks for the tip. As I said, I just took the SDL1.2 files, threw them at the wall, and they stuck. :)

BTW @user1-github @Erick555 Doesn't either of you want to take this over? You seem far more qualified than me.

@bbhtt Looks like git needs to download too much stuff from too many places, so I fought anitya after all...

I don't think it's actually using cmake now since

a. Per @Erick555

If you don't specify buildsystem then it uses autotools

b. It still accepts the decidedly non-cmake options from config-opts.

@tothxa Just add "buildsystem": "cmake-ninja" under "name".

Btw, you don't need to specify
"versions": { "<": "3.0.0"
for SDL2_image, as id 382729 is dedicated specifically for SDL2_image.

If you're using anitya, you also need to change the source url and url template to Github, as www.libsdl.org urls won't work with that. See the link to my game manifest I provided in my first comment as an example.

Unfortunately idk what maintaining shared modules involve. For me personally it's also much more convenient to just ship a dependency in my app manifest, unless it's a very old eol dependency that doesn't get updated anymore.

Btw, you don't need to specify "versions": { "<": "3.0.0" for SDL2_image, as id 382729 is dedicated specifically for SDL2_image.

I know, it was just meant for extra safety. But OK, I removed it, as well as the not built static libs from cleanup.

If you're using anitya, you also need to change the source url and url template to Github, as www.libsdl.org urls won't work with that. See the link to my game manifest I provided in my first comment as an example.

What do you mean they won't work? I've tested it: changed the versions to some old ones and changed the sha256 randomly, then ran external-data-checker --update --edit-only on them, and it updated everything back just fine. OK, maybe anitya checks the github artifacts, and libsdl.org may be updated later after a release, but I don't think that should be a big issue, and libsdl.org sounds more official...

What do you mean they won't work? I've tested it: changed the versions to some old ones and changed the sha256 randomly, then ran external-data-checker --update --edit-only on them, and it updated everything back just fine. OK, maybe anitya checks the github artifacts, and libsdl.org may be updated later after a release, but I don't think that should be a big issue, and libsdl.org sounds more official...

You mean the update with anitya checker worked with www.libsdl.org set as both source url and url template?

From what I personally know, with anitya you use the source url and url template accordingly to the specified backend in the release-monitoring page. Since for both SDL2_image and SDL2_ttf the specified backend is Github, you're supposed to use the Github urls. At least that was always the case from my experience looking at many different manifests. But if you say it works with www.libsdl.org, then idk. If you verified that it actually works, I guess you can leave that?

You mean the update with anitya checker worked with www.libsdl.org set as both source url and url template?

Yes.

1. Would you mind also adding SDL2_mixer? If not, I guess I could PR it separately once this is merged. I got it working without much trouble.
2. There's also SDL2_net in this family of libraries, but I personally don't have a project that uses it either, so perhaps it's best left for someone else to submit.
3. It might be worth checking https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/tree/release/24.08/elements/components to see what flags were previously passed when building these libraries to ensure minimal breakage when migrating. I found it helpful for getting SDL2_mixer working and it looks like some format-related options were set for SDL2_image.
4. It's probably still a good idea to switch to Github for downloads even if the current path works with Anitya, since libsdl.org downloads are seemingly deprecated, with everything pointing at the corresponding Github releases pages instead. From my understanding, the updater only fetches the latest version number from Anitya and substitutes that into the url template.

1. Would you mind also adding SDL2_mixer? If not, I guess I could PR it separately once this is merged. I got it working without much trouble.

   2. There's also SDL2_net in this family of libraries, but I personally don't have a project that uses it either, so perhaps it's best left for someone else to submit.

As far as I can tell, SDL3_mixer and SDL3_net are not yet released upstream, so their SDL2 versions are in the new runtime. We use SDL2_mixer too, and my test build succeeded without adding it as a module.

3. It might be worth checking https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/tree/release/24.08/elements/components to see what flags were previously passed when building these libraries to ensure minimal breakage when migrating. I found it helpful for getting SDL2_mixer working and it looks like some format-related options were set for SDL2_image.

I've thought of that. E.g. it's strange that using the systemwide format libraries is disabled for SDL_image... it would be nice to know the reason, as I assume it must have been important at the time...
But this is already turning into much more effort than what I was prepared for, so I don't want to track it down, and I'm reluctant to make it less efficient without knowing why.

4. It's probably still a good idea to switch to Github for downloads even if the current path works with Anitya, since libsdl.org downloads are seemingly deprecated, with everything pointing at the corresponding Github releases pages instead.

I see. Indeed, the releases link on libsdl.org points to github. Will do it.

As far as I can tell, SDL3_mixer and SDL3_net are not yet released upstream, so their SDL2 versions are in the new runtime. We use SDL2_mixer too, and my test build succeeded without adding it as a module.

My bad, the decision to remove only some libraries for the time being is a little counter-intuitive to me, but I suppose it makes sense.

I've thought of that. E.g. it's strange that using the systemwide format libraries is disabled for SDL_image... it would be nice to know the reason, as I assume it must have been important at the time...

Looking at what SDL2IMAGE_DEPS_SHARED actually does: it controls linking with shared libraries (OFF) vs runtime loading with dlopen (ON). Since flatpak environment is well-defined when it comes to the relevant image loading libraries (what's present when building is what will be present during execution), it makes sense to switch to the OFF behavior to save a little overhead.

Still, I'm more concerned about toggles for image format support, since these are the ones I expect to bite people unexpectedly.

You may see that all image formats are set to ON by default

You may see that all image formats are set to ON by default

I see. Looks like this was changed relatively recently in libsdl-org/SDL_image@542c405. In this case, perhaps enable the related SDL2IMAGE_STRICT so that missing formats aren't silently skipped during the build?

Yes, strict may be tried.

To elaborate on SDL2IMAGE_DEPS_SHARED, here's the difference:

-DSDL2IMAGE_DEPS_SHARED=ON (default, uses dlopen):

> ldd libSDL2_image.so
        linux-vdso.so.1 (0x00007f1f0687f000)
        libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0x00007f1f06795000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f1f06400000)

-DSDL2IMAGE_DEPS_SHARED=OFF (links dynamically like a normal library):

> ldd libSDL2_image.so
        linux-vdso.so.1 (0x00007fe856483000)
        libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0x00007fe856399000)
        libavif.so.16 => /usr/lib/libavif.so.16 (0x00007fe85634e000)
        libtiff.so.6 => /usr/lib/libtiff.so.6 (0x00007fe85629e000)
        libwebp.so.7 => /usr/lib/libwebp.so.7 (0x00007fe8561ba000)
        libwebpdemux.so.2 => /usr/lib/libwebpdemux.so.2 (0x00007fe8561b1000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fe855e00000)
        libyuv.so => /usr/lib/libyuv.so (0x00007fe85606d000)
        libsharpyuv.so.0 => /usr/lib/libsharpyuv.so.0 (0x00007fe856060000)
        libdav1d.so.7 => /usr/lib/libdav1d.so.7 (0x00007fe855a00000)
        librav1e.so.0.7 => /usr/lib/librav1e.so.0.7 (0x00007fe855600000)
        libSvtAv1Enc.so.3 => /usr/lib/libSvtAv1Enc.so.3 (0x00007fe854c00000)
        libaom.so.3 => /usr/lib/libaom.so.3 (0x00007fe854200000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007fe855d1d000)
        libzstd.so.1 => /usr/lib/libzstd.so.1 (0x00007fe8554ed000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007fe855ceb000)
        libjbig.so.2.1 => /usr/lib/libjbig.so.2.1 (0x00007fe85604e000)
        libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x00007fe854b15000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007fe855cb8000)
        /usr/lib64/ld-linux-x86-64.so.2 (0x00007fe856485000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fe853e00000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fe855c83000)

Thanks for the investigation and explanation.