Use libplum for RGBGFX

[pinobatch]

RGBGFX currently depends on zlib and libpng. These dependencies have proven to cause inconvenience, especially when building for Windows. When zlib or libpng maintainers issue certain kinds of update, they upload the zipfile of the new version's source code, update the web page, and delete the zipfile of the old insecure version from the server. This causes all CI statuses on all PRs to come to a crashing halt when Actions tries and fails to download zlib and libpng while building the Windows executables. See (for example) #92, #173, #469, #783, #1082, #1163, and #1202.

In a recent steering meeting, it was suggested to migrate from libpng to libplum, an image loader maintained by server member ax6 (@aaaaaa123456789). I don't know to what extent libplum depends on POSIXisms that Windows doesn't follow.

[Rangi42]

Other alternatives to weigh: libspng, lodepng, stb_image, fpng. (Haven't investigated yet, there may be reasons why one or all of these are non-starters.)

[aaaaaa123456789]

I don't know to what extent libplum depends on POSIXisms that Windows doesn't follow.

It does not. It's designed to be portable. However, it does not build under MSVC, because it requires C17, and the only C standard that MSVC properly supports is C89. (That being said, it can be built for Windows using any conformant compiler.)

[Rangi42]

It also needs bash to build, since it relies on merge.sh.

[aaaaaa123456789]

It also needs bash to build, since it relies on merge.sh.

Only from source. The releases already contain the merged files.

[Rangi42]

If RGBGFX gets rewritten in Rust, it may end up using an existing Rust library like image. But if we do want libplum, I was looking at https://github.com/alexcrichton/bzip2-rs as an example of how to write a Rust wrapper around a C library.

[ISSOtm]

The plan is indeed to RIIR (#1213), and also to switch to libplum since it provides the functionality we are interested in (in particular, palette-aware image loading) but also support for more image formats than PNG.

I had begun writing a higher-level wrapper (the low-level bindings were trivial to write thanks to bindgen), but I got stuck on how to design that crate's API to wrap around libplum. I think @eievui5 had some interest in writing such a wrapper, but am not sure if she'd be interested in designing and/or developing it after I admittedly stole her thunder... :/ (My apologies for that, if you're reading this.)

[LIJI32]

Replacing libpng with libplum has the side-effect of removing all of the runtime dependencies that are downloaded from Homebrew on macOS, which has these nice side-effects:

1. It simplifies the release build process by removing the need to hack around pkg-config, brew, etc to statically link against libpng
2. It will allow to trivially add fat-binary support in the macOS releases, so RGBDS could have readily-downloadable ARM64 builds rather than having to emulate it via Rosetta.

[orbea]

Just want to point out that libplum does not seem available or any distro yet.

https://repology.org/projects/?search=libplum

Additionally I don't see an install target in the Makefile and it hasn't been updated since 2022.

aaaaaa123456789/libplum@a809dea

[aaaaaa123456789]

I have some things I want to do for libplum 2.0, but really, it doesn't need that much maintenance. The image formats it supports have been stable for a very long time. Don't be surprised by the lack of updates!

I've never thought of packaging it, but if you want to do that, feel free. I have no idea of what an install target would look like — but do keep in mind I'm trying to avoid anything OS-specific (or compiler-specific) in the repo.

[Rangi42]

The image formats it supports have been stable for a very long time.

The QOI format is also stable (the spec is "finalized", and the people bikeshedding a v2 never got anywhere), and I hope that PR will make it into libplum 2.0. Not that it really matters for RGBGFX; all that cares about is PNG support, which is also a "frozen" spec (changes are done with backwards-compatible chunk types).

[Rangi42]

Also note that the Rust rewrite has already completed the RGBGFX portion, using the plumers wrapper around libplum. (Although there's no ETA for rsgbds to be complete; rewriting the assembler is a big task.)

[ISSOtm]

Note that any image format supported by libplum is nice (e.g. rsgbds supports BMP inputs. That's nice, probably.) but not critical.

[orbea]

I've never thought of packaging it, but if you want to do that, feel free. I have no idea of what an install target would look like — but do keep in mind I'm trying to avoid anything OS-specific (or compiler-specific) in the repo.

Many distros either strongly prefer or perhaps some even require that libraries be installed system-wide and not vendored. For a complete install target it would need to install a versioned library, any public headers and preferably something like a pkgconfig file. The easiest way while avoiding OS specific checks would be to use a build system like autotools (Darwin, Windows and Unix have different library extensions and compiler flags), however it can be done in a static Makefile too with some effort.