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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.