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.
* GNUInstallDirs is the only Kitware-supported
way to change the default directories. Most
distributions have hooks for changing these
directories, which makes integrating wesnoth
easier and more consistent with the rest of
the CMake ecosystem.
* Make build system perfectly out-of-source
compatible. The build system should never
touch files in the source tree.
* GNUInstallDirs is the only Kitware-supported
way to change the default directories. Most
distributions have hooks for changing these
directories, which makes integrating wesnoth
easier and more consistent with the rest of
the CMake ecosystem.
* Make build system perfectly out-of-source
compatible. The build system should never
touch files in the source tree.
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.
Apparently due to a CMake bug, some (but not all) CMake versions attempt to
compile the test with default flags, which means C++98 mode with GCC < 6.
As a result, compiling the test fails, and the whole game fails to build.
@gfgtdf pointed out to me that CMake reports the compile and run status
separately, and therefore it's possible to detect the situation where the
test fails to compile. Thus, I decided to allow building in that situation.
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
When using:
scons strict=true ctool=clang
A number of issues appear concerning a known bug in Boost::Bind; applying the patch which should appear in Boost 1.63. Comments on the Boost ticket indicate this may also be an issue for earlier versions of GCC.
For the ticket, see
https://svn.boost.org/trac/boost/ticket/12397
and the patch is at
3c56630b54
NOTE: This does NOT create a dependency upon the patched header. If the header is changed, you must do a full re-build of all sources by hand.
The code conditionals using SDL_gpu in the source tree are unmaintained
and likely broken. From past discussions with vultraz and Aginor, the
plan ahead is to completely drop SDL_gpu and its support code once
there's no risk of conflict with certain WIP branches.
Pretty much all of the code for supporting OpenPandora is gone from the
source tree, and the last two mentions have just been slated for
removal, so it's effectively dead.
