Commit dfc42e8a8d removed said code since
Wesnoth can use IMG_SavePNG() from SDL_image 2.0 instead. However, the
author left the build-time configuration options intact, and also part
of the necessary code for CMake to link Wesnoth against libpng.
Note that this change also eliminates an unnecessary direct link-time
dependency on libpng when using both CMake and SCons.
(cherry-picked from commit 4799ca05fe)
This reverts commit 44f567c6a3.
Enabling LTO by default causes too many problems, inclusing build
failures for @doofus-01 and link failures with Clang for me.
Players and packagers can still amanually enable LTO in case it
works fine for them.
The detection for when Clang is used was incorrect, resulting in GCC-only
parameter being passed to Clang.
In addition, at least on my system LTO+Clang caused linking errors even
with that fixed. As an emergency fix, I completely disabled LTO for Clang.
LTO for Windows is disabled for now, as TDM-GCC does not work well with it.
LTO for Travis is also disabled, due to the extra time linking with LTO takes.
This moves all the warnings flags from the strict build to the regular build, except for -Werror. This means that the only difference between strict builds and non-strict builds will be if warnings are turned into errors.
This quells warnings from CMake about reserved target names, and reduces confusion about which `test` is intended: the wesnoth executable or the standard shell command.
We have needed to suppress it in a bunch of places because GCC has kept
giving false positives depending on optimization settings. When I noticed
yet another false positive when I attempted to build the game with PGO
profiling data using CMake, it was the last straw.
Let's just suppress the warning globally and move on with our lives.
At branch 'doc-from-discord-boost-discussion-20170926'.
The build documentation and scripts were slightly out of date about
Boost. This commit makes a (probably interim) update to them.
(CMakeLists.txt|SConstruct): `wesnoth` won't build using Boost earlier
than '1.50.0'. Boost 1.50.0 changed the location of version 3 of Boost
filesystem, from 'boost/filesystem/v3/' (e.g. for
'using boost::filesystem::v3::path;') to 'boost/filesystem/' (e.g. for
'using boost::filesystem::path;', enforced since the very introduction
of 'src/filesystem_boost.cpp'), making it incompatible unless using
precompiler directives for supporting backwards versions of Boost
filesystem prior than '1.50.0'. Using Boost 1.50.0 (and 51, 52 etc.)
`wesnoth` is able build and run. I checked using `ldd` that I am right
about the run time environment.
INSTALL.md: Requirement of Boost libraries version up to date.
projectfiles/VC12/README.md: Requirement of Boost libraries up to
date, only the statement of which one is the minimum version, not the
rest of the build guide for Boost as requirement.
.gitignore: Add KDevelop backup documents.
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.)
This is needed because the CAIRO_STATUS_INVALID_SIZE constant was added in
that version.
1.10 is old enough that this change shouldn't cause problems for anyone.
For example, Debian Wheezy (2013) has Cairo 1.12.2.
By default, TDM-GCC-64 was using -march=x86-64, which for whatever reason caused issues when compiling with -O3. This makes scons force it to use -march=pentiumpro, the same as TDM-GCC-32. This also changes the release build to use -O3 instead of -O2, which matches the release build default used by cmake and code::blocks.
Added -march=pentiumpro on Windows for -O3 build
m5
Check if LTO is enabled
Add LTO flag
Added a flag to enable/disable LTO. Also pass optimization options to the linker, since older versions of gcc may not automatically use the same options for linking and compiling, and it seems likely clang doesn't do this either.
m3
This is Chrome-only and W3C is said to be working on a portable alternative.
There is an x86-64/i686 version 1.10 of BfW on the Chrome web store. There appears to be no interest in upgrading to curret versions of NaCL and supporting the Chrome-only plugin.
These include an alternate mode of normalize_path() that enforces the
platform's preferred path delimiter (i.e. backslash on Windows) on the
output, and a function to detect whether a path refers to a root
directory.
Unfortunately, the last bit requires introducing a new link-time
dependency on Windows, against a system library. It's guaranteed to be
always there but it seems kind of a waste. The alternative would be to
hand-parse the string but that seems even more of a waste. And no,
Boost.Filesystem can't do this in a straightforward fashion right now.
Needed since 0180a72573 introduces the
requirement of a C compiler in the building process. Otherwise we get
this from GCC 6.1.1:
cc1: error: command line option ‘-Wold-style-cast’ is valid for C++/ObjC++ but not for C [-Werror]
This adds -Wold-style-cast to the CCFLAGS when compiling everything
but lua. Lua requires an exception from the flags and there's thus a
workaround added.
This drops the required version to 2.0.2 on Linux and *BSD, as there are no known bugs that require us to have a later version on these platforms. Windows and Os X remains as 2.0.4.
How does doing otherwise even help reduce compile times unless you are
changing your build environment every time? It's just a liability that
makes it harder to do feature detection from other files. It's also
asymmetrical with regards to the CMake recipe.
This option cleans up some of the compatability path code from the
1.12 release. After this commit:
- boost::filesystem becomes a hard dependency, for scons
- boost::locale is a soft dependency, a build flag "libintl"
allows to swap boost::locale out for libintl.
- the libintl flag cannot be used when compiling for windows
It was reported on Dec 22 2014 in irc that the game is broken if
this is missing, and a search shows that bigmaps and many campaign
story screens use jpg images.
It makes more sense imo to document this as an official dependency
now, and if we decide to change everything to png's then we can go
back and disable the jpg check then.
The option should control the compilation, in wesnoth-core, of
filesystem_boost.cpp, and gettext_boost.cpp, vs. the old versions.
Using the new code is now the default option, you must explicitly
deactivate with both cmake and scons to get the old stuff back.
This commit adds a "minimal interface to lib png to support writing
png files from SDL surfaces", to the codebase. It adds a save_image
function to namespace image, and this checks compiler flags to see
if lib png is available. The function will save as a png if png
support is included and save file name doesn't have bmp extension,
and otherwise it will save as a BMP as usual.
We already had lib png as a dependency to build the tools, just not
the main game. This commit changes cmake and scons but makes the
dependency only optional, changing nothing if lib png is not
available.
See here: https://github.com/driedfruit/SDL_SavePNG
SDL 1.2's own filesystem functions have very limited unicode support,
so provide an SDL_RWops struct to let them use ours.
This also bumps the minimum required SDL_mixer version to 1.2.12
Conflicts:
SConstruct
src/filesystem.hpp
This moves messages about optional SDL libs checks below
potential warning about missing base dependencies and
makes SCons check GCC compiler before SDL.