Re: Add PNG_ARM_NEON switch to CMake
John Bowler <[email protected]>
| Newsgroups | gmane.comp.graphics.png.devel |
|---|---|
| Message-ID | <CAP7U398_Au-gT1XQ0jE9z8sZ6bH1bF=eHwQBi5uVWRA_pHqt7w@mail.gmail.com> |
Regardless of the cmake stuff there seems to be some misunderstanding here, from the comment (the change matches this): "Behaviour is copied from autoconf; by default PNG_ARM_NEON is set to 'check' and NEON support is checked dynamically at runtime. Other possible values are 'on' and 'off'. The deprecated option 'api' is not used here." The *default* is, and must be, to not set PNG_ARM_NEON. It is the 'check' option which is deprecated! It only works on a subset of GNU/Linux operating systems, so enabling it by default will break libpng on pretty much everything except the slew of IoT devices that are not secure. In any case the only reason --enable-arm-neon still exists in 1.5 and 1.6 (it isn't in 1.7) is that it was a part of the original, very broken, implementation. All it does is set certain build configuration CFLAGS, however as was pointed out soon after people started moving from 1.4, this can't be done at configuration time; it has to be done automatically at compile time. Libpng 1.6 and, I think 1.5, automatically handle the ARM NEON optimizations. I'm not aware of any situation where this doesn't work though as with any configurable item of libpng people might want to change things; this is done by setting CFLAGS when pnglibconf.h is built. John Bowler ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi