If no build type is selected it can happen that the game builds without
any optimization. Now the user has to explicitly specify the 'none'
type if they want it.
Conflicts:
CMakeLists.txt
I also fix up earlier backport of this content,
cef5e2ed9c
so that when pandora overrides BFS setting, the SDL mixer
requirement is relaxed appropriately.
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.
Conflicts:
CMakeLists.txt
SConstruct
Also I squash in this commit, adding boost locale to travis:
48217f8da0
This was checked to compile (but not link of course) on my system,
using cmake with pandora enabled, and pointed to the SDL_mixer
1.2.0 header. (the master version, not this cherry-pick)
I also essentially backported this commit:
cef5e2ed9c
which checks reduces the CMake version requirement for pandora
Clang 3.4 is unhappy that Doxygen comment with @deprecated is not
accompanied with a deprecated attribute. Since we don't do that, disable
the warning.
Extension of commit 329e7cea96 by fendrin. Now when a build parameter
is defined, the cmake recipe will no longer link in libvorbisfile (just
linking it in makes the app crash when ogg-vorbis music is played).
This flag is used on strict compilation to avoid warnings regarding the
register keyword being used. It is used in several system headers and the
upcomming Clang 3.4 warns about it.
Not setting this can cause compiler errors when using std::max or
std::min, as the windows header defines macros with these names otherwise.
The standalone project file was doing it that is why I didn't get said
errors there.
The dependency's version is decreased to version 1.21.3. This is the
version currently used in XCode (on the Mac). Upgrading there is
troublesome.
This partly reverts 2b939cebc7.
It gives problems when using Clang and boost::shared_ptr when compiling
for C++11. The issue can't be fixed since Wesnoth uses C++98. (So we use
NULL instead of nullptr.)
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.
It has the following issues:
- Only works if the user has installed systemd development headers.
- Must install the game or unit test to be able to detect systemd.
- Doesn't work if wesnothd has a prefix or suffix in its name.
- The user has no way to opt-out; installing wesnothd doesn't mean it
has to be started by default.
It is intended to address all those issues, but it should delay the
release of 1.11.0.
At the moment the flags are determined on the first run and stored in
CMAKE_CXX_FLAGS, CMAKE_CXX_FLAGS_DEBUG and CMAKE_CXX_FLAGS_RELEASE[*].
This was actuall not a good idea, since CMake combines CMAKE_CXX_FLAGS
with the CMAKE_CXX_FLAGS_<BUILD_TYPE>. The problem with this setup is
when the compiler is changed the flags are reset to their defaults and
the user made changes to the flags are lost. The second issue with the
old implementation is that the ENABLE_STRICT_COMPILATION CMake option
must be directly set; changing its value after the initial generation
had no effect.
The change will only set CMAKE_CXX_FLAGS, based on the environment
variable $CXXFLAGS, this is stored in its own variable, named
CXX_FLAGS_USER, in CMake and can be changed later. This flag is only
initialised on the first run. It is also based on the default flags we
use for Wesnoth and the _current_ state of the ENABLE_STRICT_COMPILATION
option. For the transition from the old to the new system the old
CMAKE_CXX_FLAGS are used as initial value for the CXX_FLAGS_USER. This
means no flags are lost, but some extra flags are added, will CMake to
cause a recompilation. So it's advised to regenerate the project files
or change the CXX_FLAGS_USER after CMake as updated the flags.
[*] Note I removed the CFlags since all C based code has been removed,
with the removal of the poolallocator.
The Clang compiler now also defaults to strict compilation when building
with CMake. Also the default flags have changed to the ones used for GCC.
This has only be tested with Clang 3.1.
