Re: [PATCH v2] arm: Don't require a runtime check function for targets with unconditional NEON

Cosmin Truta <[email protected]> Tue, 11 Oct 2022 22:01:23 +0300
Newsgroups gmane.comp.graphics.png.devel
Message-ID <CAAoVtZy1SWPvgdFwZ0-oD7Vos00ettbiA9udVKaZYufzC=1=-A@mail.gmail.com>
On Tue, Oct 11, 2022 at 7:07 PM John Bowler
<[email protected]> wrote:

> PNG_ARM_NEON_OPT is a *setting*, PNG_ARM_NEON_CHECK_SUPPORTED is an *option*.

Reading this statement reminds me how insanely over-engineered the
libpng build configuration system is. What other library or codec
comes even close? (This is not a rhetorical question, and I'm not
trying to be sarcastic here; just asking about best practices employed
elsewhere.)

> I suggest at this point simplifying it

I vote yes in principle to pretty much any statement that has the word
"simplify" in it. Not for libpng-1.6.x (because I'd rather not cause
gratuitous workflow disruptions for any of our users), but for the
future versions.

> remove both NEON and VSX option handling, remove PNG_ARM_NEON_OPT and remove the runtime API; by remove I mean simply ignore it (since it is a png_set_option API).   See what breaks; most likely nothing.  For sure remove the code from pngpriv.h; ARM, MIPS and POWERPC alike.

I'm ok with this if we don't break the current behaviour; otherwise it
should be left for after 1.6.x.

> Nope; you are fixing a cmake bug by breaking an API.  Sure, removing the API is fine, but just breaking it because of a simple failure to update CMakeLists.txt is clearly wrong.

The cmake build has been changing its behaviour all the time, while
the configure build has been quite stable.

I agree with the suggestion to change the cmake build behaviour in
order to make it follow the configure build behaviour.

Sincerely,
Cosmin