Willingness to add Package.swift file? about libpng HOT 3 CLOSED

Hi, @daltonclaybrook,

I am personally fond of the Swift programming language, but I am also preoccupied about the idea of opening flood gates to all the other languages out there. I rejected a cocoapod in the past, also, for the same reason. Now, if I would add a meson build file, or a conan file, at least that would be for native C and C++; but even those ones would be a non-trivial story, considering that we already have three build systems that need regular maintenance and verification. (See ci/ci_verify_*.sh.)

On the other hand, if our current CMake-based build system isn't sufficient for an official SwiftPM that's maintained externally in a manner that's similar to how they do it in the official VCPkg package repository, or in the official Conan package repository, but a solution that's native to C/C++ would work for you (e.g. adding a Conan package inside libpng that you would then use in your external Swift package), then I'm open to such ideas.

One last alternative, if that would work for you: if a SwiftPM package would not require (too much) maintenance, I am open to the idea of adding a subdirectory, let's call it contrib/build/swiftpm, for your convenience, while making it clear that it isn't tested by us in an official capacity.

One last thing: I'm closing this issue, and I am (admittedly, very slowly) moving everything https://github.com/glennrp/libpng to https://github.com/pnggroup/libpng -- feel free to open a follow-up issue in there, with specifics about how you would like to proceed.

from libpng.

from libpng.

An addition consideration for the contrib/ directory: Zlib has a contrib/ directory and in my opinion, it accumulates cruft. Those contributions rarely seem to be maintained. Ut they also don't have a deletion policy. If you go the contrib/ route, you might want to consider something like a yearly ping to confirm it still works as intended. (No reply for 3 months = deletion. It is in git history if someone wants to dig it out.)

That's why I said "if a SwiftPM package would not require (too much) maintenance" -- perhaps I should have said "if it doesn't require any maintenance" ;-)

In fairness, the cocoapod that I rejected a few years ago was rather tame.

Regardless: point taken.

FWIW, I have had it in my plans to start testing the currently-contributed mini-projects (contrib/gregbook, contrib/pngminus, contrib/visupng, etc.) on the CI bots, because, yes they are decades old, and yes they should be still working. They should serve as additional tests for the continuing stability of the libpng API. And I will make that happen also... eventually...

from libpng.