In some cases, the vector extension is not supported, although the
compiler allows the "v" flag in `-march` and includes `<riscv_vector>`
without raising an error.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
A funny thing happened while refactoring the function argument parsing
in the `PNGGenConfig` module: the processing of dependencies inside
the CMake function `generate_copy` got fixed, thanks to an inadvertent
typo correction!
Going down the rabbit hole, we uncovered two issues:
1. A typo in `scripts/cmake/PNGGenConfig.cmake` caused a dependency
declaration to disappear, disrupting the graph. Fortunately, this
disruption was being mitigated by an additional set of (redundant)
symbolic target declarations that kept the CMake build going.
2. The exact string matching inside `scripts/cmake/gensrc.cmake.in`
imposed an artificial limitation, disallowing the use of absolute
file paths.
The typo correction in (1), and the use of regex matching instead of
exact string matching in (2), allowed us to use absolute file paths
in the main CMake file, consistently, thus allowing CMake to recognize
them as uniquely-identifiable nodes in the dependency graph. There
should be no further need to have extra symbolic targets for proper
node identification.
In the end, we shaved off the redundant symbolic target declarations,
retaining only `png_genfiles` and `png_genprebuilt`.
Counter-intuitively, defining the PNG_DEBUG macro as 1 (i.e. setting
the debug verbosity level to 1) does *not* cause any of the existing
debug traces to show up. This setting would have worked if we had trace
statements like `png_debug(0, message)`, but we don't have any.
Debug traces do show up for verbosity levels from 2 to 5. The libpng
manual describes in detail how they are meant to be used.
According to the history of the CMake file, as well as the history of
other project files, PNG_DEBUG was never set to a numeric value larger
than 1. In other words, these debug settings inside these build files
never produced any output in any (unmodified) libpng version.
(As for the configure build, PNG_DEBUG has no special treatment there.)
Considering the plethora of alternative methods to pass C preprocessor
options through our build files, scripts and projects onto libpng, we'd
rather discontinue PNG_DEBUG as a dedicated build option.
Allow the CMake build to work properly, even if file paths (in the
source directory, in the build directory, or in the install directory)
might contain whitespace characters.
Improve the check for compilers that might use MSVC Runtime library
headers on Windows. We use POSIX-ish ("deprecated") functions, even
on Windows, and we want no spurious warnings.
Tidy up the CMake file: rearrange declarations, rewrite comments, etc.
Running the pnglibconf scripts (script/*.awk) is not always possible.
An AWK interpreter is not always guaranteed to be available; and even
if it is, there are limitations when making cross-platform libpng
builds, especially when the differences between the host platform and
the target platform are significant. For example:
* Building for the Windows (MinGW) target on a Unix development host;
* Building for the iOS target on a macOS development host;
* Building for the Android target on any development host.
In such scenarios, a preconfigured (i.e. prebuilt) pnglibconf.h file,
either taken from the libpng source tree or provided by the user who
wants to make a custom libpng build, becomes a necessity.
In this commit we introduce the build option `PNG_LIBCONF_HEADER` in
order to address this specific use case.
We also specify a version range (3.14...4.0) for the minimum required
CMake program, to future-proof the CMake build for just a little bit
longer.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
In preparation for the upcoming changes in the build system, any parts
of the CMake file that are unlikely to be affected should be moved out
of the way. This should facilitate an easier resync between the branch
'libpng16' and its successor(s).
Specifically:
* Move the functions `generate_chk`, `generate_out`, `generate_source`
and `generate_copy` to scripts/cmake/PNGGenConfig.cmake.
* Move the function `png_add_test` to scripts/cmake/PNGTest.cmake.
* Leave the function `create_symlink` in place, but add a TODO note.
As we raised the minimum required CMake version to 3.14, we should
now be able to use CMake's built-in function instead.
Update the main CMake file and the auxiliary test scripts accordingly.
This is a cherry-pick of commit fe277b7752990be35523832a546aec478437968a
from branch 'libpng18'.
This chunk was added in the third edition of the PNG specification and
contains Coding Independent Code Points (related to color space
description). It is fairly simple as it only contains four fields of one
byte each: Colour Primaries, Transfer Function, Matrix Coefficients,
Video Full Range Flag.
The test file originally comes from the related WPT test case:
https://github.com/web-platform-tests/wpt/blob/master/png/support/cicp-display-p3.png
Note that I reencoded the file to make it match libpng's default
encoding parameters (it only modifies the IDAT chunk).
This is a cherry-pick of commit 65925ad4b2cbed934d5d850fe764dc46c4becbcb
from branch 'libpng18'.
Reviewed-by: John Bowler <jbowler@acm.org>
Reviewed-by: Chris Blume <ProgramMax@gmail.com>
Reviewed-by: Cosmin Truta <ctruta@gmail.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Introduce CMake file linting, based on the cmakelang project by
Josh Bialkowski (@cheshirekow).
Fix various style issues in the CMake files:
* Add the missing copyright header to PNGConfig.cmake.
* Resolve a "missing docstring" warning raised by cmake-lint.
* Rewrite all docstrings in the style of CMake's own documentation.
* Fix whitespace inconsistencies.
References:
* https://pypi.org/project/cmakelang
* https://github.com/cheshirekow/cmake_format
This is a cherry-pick of commit c317fe31114d92d05d44bf98c9b559edf4656b9c
from branch 'libpng18'.
The leading blank lines are apparently an artefact of an older source
control system. They are not required and they look like accidents,
because starting a source file with a blank line is not a regular habit
of software developers nowadays.
This is a cherry-pick of commit 37cc20add8fb5b83bb5299a26cd3b41e0f776017
from branch 'libpng18'.
Signed-off-by: John Bowler <jbowler@acm.org>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Start using the features guaranteed to be available in CMake 3.14.
Specifically, use the ability of `find_package(ZLIB)` to pick up zlib
from the ZLIB_ROOT variable (if given).
This is a cherry-pick of commit 00343a761e41e56acaeb0517aec5325d3b951837
from branch 'libpng18'.
Properly declare target include directories for generated includes.
Previously the non targeted `include_directories()` was used, which
had issue when using the `png_static` target in a submodule.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Properly declare target include directories for generated includes.
Previously the non targeted `include_directories()` was used, which
had issue when using the `png_static` target in a submodule.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Because of a missing "amd64" string (in lowercase) in a regex match,
the CMake build was unable to pick up the PNG_HARDWARE_OPTIMIZATIONS
flag on FreeBSD/amd64 (and possibly other amd64 systems as well).
Rename the target arch variable from TARGET_ARCH to a more idiomatic
PNG_TARGET_ARCHITECTURE, and set it to an always-lowercase string.
The follow-on checks are now simpler and easier to get right.
This file contains hand-coded assembler implementations of the filter
functions for 32-bit Arm platforms. These are only used when the
compiler doesn't support neon intrinsics (added to GCC 4.3 in 2008) or
is exactly GCC 4.5.4 (released 2012), both of which are sufficiently
unlikely to be true that it's fair to say the assembler is no longer
used.
This commit deletes filter_neon.S and removes the now obsolete
preprocessor logic in pngpriv.h.
Signed-off-by: Bill Roberts <bill.roberts@arm.com>
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
This fixes the bug https://github.com/pnggroup/libpng/issues/505
"libpng does not support PAC/BTI on aarch64 targets" which arises
because the build mechanisms (both cmake and configure) assemble
arm/filter_neon.S even though it ends up completely empty. The empty
file effectively poisons the so that the PAC/BTI support gets disabled.
The fix is minimal; it simply removes arm/filter_neon.S from the list of
sources included in the 64-bit ARM builds build. Note that this was
already done in cmake for MSVC - it's not clear whether this change was
a partial fix for the same issue.
This version of the fix ONLY affects aarch64 (arm64) builds; 32-bit ARM
systems can still invoke the assembler if required and, indeed, there
should be no change whatsover to those builds.
The assembler code could not be used on 64-bit systems in any case so
in practice there is no material change to 64-bit builds either.
TESTING: pull the changes then type "autoreconf" if using configure (not
required for cmake).
TESTS: cmake has not been tested because cross-builds with cmake
currently fail to find the zlib installation from the cmake system root
path. The following has been tested with configure cross builds:
armv7-linux-gnueabi [no neon support]
armv7a-linux-gnueabi [no neon support]
armv7a-hardfloat-linux-gnueabi [neon support not enabled]
armv7a-hardfloat-linux-gnueabi -mfpu=neon [uses intrinics]
armv7a-hardfloat-linux-gnueabi -mfpu=neon
-DPNG_ARM_NEON_IMPLEMENTATION=2 [uses assembler]
aarch64-linux-gnu [uses intrinsics]
aarch64-linux-gnu -DPNG_ARM_NEON_OPT=0 [neon support disabled]
Signed-off-by: John Bowler <jbowler@acm.org>
Modern compilers can disable the warnings that originate from system
headers. This change allows them to do so with the libpng headers.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
Update the PNG_TOOLS option: set it to OFF by default when the
target is an embedded system, yet still allow it to be overridden.
Update the PNG_FRAMEWORK option: force it back to OFF and print a
warning if the option was ON but the target is not an Apple system.
This fixes commit 4edbb4da81626a7342a22824d7a8f60a3ea71bd0.
During the move of CMake scripts to the scripts/cmake/ subdirectory,
some of the workflows have been broken.
Signed-off-by: Cosmin Truta <ctruta@gmail.com>
From the libpng licensing point of view, the build projects, the build
scripts, the test scripts, the CI verification scripts, et cetera, have
not traditionally been part of libpng proper, although some of these,
including the CMake-based build, have been released under the libpng
license.
Considering how the CMake build grew as a result of many contributions
from many contributing authors over a long time, one may argue that it
almost became an individual piece of software in its own right.
Moving on, everything CMake-related shall be placed in the subdirectory
scripts/cmake/ (except, of course, the main CMakeLists.txt). Moreover,
contributing authors shall be acknowledged in scripts/cmake/AUTHORS.md.
Please see scripts/cmake/README.md for more information.
