The design of po4a seems to expect it to act as a build system,
running with a config file telling it which files to build. In
version 0.68-1, the po4a-gettextize tool has changed to error out
with a comment that it's not being run the way it expects.
See https://bugs.debian.org/1020821
po4a-updatepo works for now with 0.68-1, although it prints a deprecation
message.
* the FindSDL2 module forwards to CONFIG mode first
* if that fails (eg. no -version.cmake or config not even present) it
uses pkg-config
* exports SDL2::SDL2 and SDL2::SDL2main as targets
* fix missing IMPORTED_LOCATION for other build types in Vorbisfile
Make the search for translatable strings include
install_dependencies.cpp in the POTFILES.in file.
Simplify the quoting and escaping, and only open
the POTFILE.in files for writing once each.
This is intended to allow xgettext to extract plural forms from the code
without actually altering the input. Basically, this is to _n() as N_()
is to _(), and doesn't actually call any gettext functions.
It seems that FIND_PACKAGE_HANDLE_STANDARD_ARGS is doing a case-sensitive
search for whether the find_package flags included REQUIRED.
(cherry-picked from commit f259976659)
This also removes the included SHA1 and MD5 implementations
in favour of those from OpenSSL.
Thanks to @jyrkive for helping to get the CMake build working and
ensuring the game still compiles with OpenSSL 1.1.0.
(The SHA_xxx() aliases were removed in OpenSSL 1.1.0.)
* FriBiDi can be found using pkgconfig, switch to using it instead of
using our homegrown FindFriBiDi.cmake file for finding it in cmake
* had to set some extra "do not consider these warnings" for font.cpp,
is this really no issue for scons for strict compilation with -Wall?
Fixes CMake being unable to find FriBiDi here on Debian jessie.
Commit 651344ee1b introduced something
that looks more like post-processing syntax used by MacPorts and doesn't
appear in CMake's documentation. Reverting this commit fixes FriBiDi
detection for me, but the original approach of hardcoding search paths
seems unnecessary as far back as CMake 2.6.0, our minimum supported
version. This is because find_library() and find_path() both use CMake's
configured system prefixes automatically and provide a PATH_SUFFIXES
option with suffixes to use for e.g. locating FriBiDi's include dir
(/usr/include/fribidi here).
Without this, rebuilding the game manuals fails because
/usr/share/asciidoc/docbook-xsl/xhtml.xsl doesn't exist. We need to use
/etc/asciidoc/docbook-xsl/xhtml.xsl instead here.
(Default shell as in the /bin/sh executable.)
On Debian and other systems using a different Bourne-compatible shell
that doesn't support some of Bash's syntax extensions (in particular,
'&>' as a redirection operator targeting stdout+stderr), the pot-update
target is completely broken, stuffing the POTFILES.in lists for either
the last (wesnoth-utbs) or first (wesnoth-ai) textdomains with paths for
every C/C++ source file from our tree.
Shells that do not interpret &> the way Bash does consider it to be the
stdout redirection operator following an asynchronous invocation. Of
course such a thing is bound to cause weird issues like this.
Most references to and dependencies on Subversion have been removed.
"+svn" is now "+dev". Files that can't be fixed yet have a FIXME-GIT
comment in them; most of these are in the website tests.
Newer versions don't define a symbol directly confusing cmake, fixed by
letting the compiler test whether it really doesn't exist. The issue was
spotted by Espreon.
