Re: [PATCH] cmake: Default to PNG_ARM_NEON=off for arm targets

On Thu, Oct 13, 2022 at 9:48 PM John Bowler
<[email protected]> wrote:
> I double checked.  It is exactly as I said; if you do not pass *any* command line arguments to configure you get the relevant (target) CPU optimizations compiled in so long as the compiler supports them.  (The latter check happens in pngpriv.h, which, as I said, is probably the wrong place.)

The same goes for the CMake file. I actually tested it.

It is worth introducing a new API function that informs the user about
the available optimizations. Let us call it, tentatively,
png_get_compile_flags(void) returning uint32_t. (In zlib, there is a
similar function named zlibCompileFlags()). We can return all kinds of
flags, including a flag that can be named
PNG_COMPILE_HARDWARE_OPTIMIZATIONS.

> Running configure determines the target architecture (that's just configure).  Yes, it's a mess:
> [snip]

So, John, to conclude your point: do you agree that Martin's patch
does the right thing, or do you not? And if not, then what is the
correct solution in your opinion?

Because I do agree with Martin's patch, and I do believe that the
patch does the right thing.

As for multilib working (or not), feel free to submit a modification
to the periodic verification of libpng. See the files inside
libpng/ci/ci_*.sh.
I'm running the automated test suite on Travis CI and AppVeyor CI, on
FreeBSD, Mac, Linux and Windows. I am also running tests on Bob's
Solaris machines, manually.

https://app.travis-ci.com/github/ctruta/libpng
https://ci.appveyor.com/project/ctruta/libpng

Going further, whatever it is that we claim that works, it will need
to be verified with an appropriate test on the CI bots.

And whatever we claim that was broken and it's being fixed, a test
should be added and verified. The multilib build is important and it
should fall in this category.

Sincerely,
Cosmin