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.
In gcc-4.8 there will be a new warning -Wunused-local-typedefs. This
warning is triggered by boost's static asserts, causing strict
compilation to fail when using this compiler.
Note the compiler is not officially released yet so used a recent
snapshot.
The use of shared libraries makes compilation debug versions faster but
results in extra shared libraries. For installation this is not
practical since the libraries need to be given SONAMES and kept in sync.
Therefore installation is not supported for this option and will
probably fail.
The statistics for the change are:
Static build:
- Normal:
real 20m51.604s
user 19m47.838s
sys 1m5.100s
size 94MB
- Debug:
real 24m48.577s
user 23m3.114s
sys 1m22.305s
size 1.9GB
Shared build:
- Normal:
real 21m5.141s
user 19m56.879s
sys 1m7.692s
size 29MB
- Debug:
real 24m24.239s
user 22m55.278s
sys 1m20.193s
size 596MB
So the build times don't change that much but the sizes do. When
rebuilding after changing a file the build times start to improve for
the shared build, but not timing done.
This affects the cmake and scons scripts, and various project files in
projectfiles/. I have only tested my changes to scons (and loonycyborg
might still want to review the diff regarding a line in src/SConscript
involving game.cpp).
It fails to link some standard libraries.
Forcing files to be C++ files doesn't set the proper compiler switches
for clang.
Tested with clang 2.9, there are still compilation errors to be sorted
out.
When the game is disabled from the command line the unit tests no
longer compiled. When using cmake normally the game is automatically
enabled and disabling it afterwards doesn't introduce the bug.
