libpng18: entry to beta

[jbowler]

This issue tracks open issues with respect to libpng18 entering beta.

[jbowler]

I've submitted all the pull requests I had pending a new major release and all of these pull requests have been resolved one way or another. Consequently I do not expect to submit any development PRs for libpng18. Therefore I am happy with libpng18 becoming a beta release.

[ctruta]

Thank you, John. Your contributions have been aplenty, and they are appreciated aplenty.

This is nothing but an FYI: I want to do more cleaning before making it a beta, because now is one of those opportunities.

Should you change your mind, in the sense that you'd like to start deleting things (with the very well-known qualification that we don't and won't break user apps), I will welcome your deletions 😉

[jbowler]

The changes I've already submitted and had accepted will sufficiently break your workflow; the changes to the hardware handling even without the file moves will certainly cause merge conflicts if there are any significant bug fixes in those parts of the read transform code.

This is likely because that code is broken in many ways; it lives on by a lack of demand (so it could be deleted) and a lack of inclination on the part of those who actually use it to report bugs rather than work round them and rant in their own rant-space about how it's a bug in libpng.

Nevertheless releasing 1.8.0 at this point will give you additional workspace because you can simply say "fixed in 1.8" after fixing it and then you can fix it one way in 1.6 and a different way in 1.8.

So go for it: Do all the remaining deletions you want in 1.8 and release the thing, as I said elsewhere with regard to the wall.

I'll certainly help with the prebuilt files stuff; I believe it's only in configure and I sort-of understand that particular PoS.

It's something of GNU that I greatly admire though maybe no so much as Larry Wall. Though we build on the shoulders of giants we remain shorter; reality is the Poisson distribution.

[jbowler]

ISSUE: continuous existence of machine generated files in this github

[ctruta]

ISSUE: continuous existence of machine generated files in this github

I agree in principle, but with an important qualification. Other than that -- PR, please? ;-)

Important qualification

If you @jbowler meant to say that we should the remove the artifacts whose generation involves AWK in some way or another: yes to that, too, but we have a couple of snags to resolve first. Those snags deserve to be addressed in their own separate issue.

• Small problem: AWK is not available on all build platforms.
• Medium problem: annoyances in cross-platform builds in general.
• Big problem: blockers in cross-platform builds for Android and iOS.

[jbowler]

@ctruta: are you suggesting removing the machine generated files, such as configure, from the tarball as well as the GIT archive?

I'm just suggesting removing them from GIT, so when the tarball is generated they all get generated. Given that all of them are somewhat tricky to generate correctly it seems reasonable to do this.

Getting awk on a platform which supports a compiler is a lot easier than getting autoconf :-)

[ctruta]

@ctruta: are you suggesting removing the machine generated files, such as configure, from the tarball as well as the GIT archive?

Nope. Only from the Git archive. The distribution tarballs should contain everything that's needed.

Given that all of them are somewhat tricky to generate correctly it seems reasonable to do this.

Except... see the small problem, the medium problem, and the big problem, above.

Getting awk on a platform which supports a compiler is a lot easier than getting autoconf :-)

True for Autoconf; false for CMake (and for Conan, and for Meson, and for everything else that's not Autoconf). Annoying on Visual Studio on Windows (in my personal opinion and experience). And relevant for the first problem only, but not for the last two.

[jbowler]

If the tarballs have the machine generated files there's no issue for unsupported build systems.

The second and third issues are down to the lack of a maintainer. It would be nice if AndroidStudio, the Apple iOS build system and VisualStudio all supported minconfigs because the people using them aren't/can't/shouldn't be installing system DLLs but that's a separate issue and certainly requires specific maintainers first. Even then when I was maintaining the Visual Studio build I didn't bother with the minconfig stuff because that would have been additional work/documentation/bug reports/misunderstandings.

Yeah. There should be issues here for unmaintained but widely used build systems. Likewise for cross build issues, however the only one I am aware of at present is that 1.6 cmake is still broken on MacOS multi-arch builds. So far as I know iOS and Android are both single target so should be ok.