wesnoth/RELEASE_NOTES
Mark de Wever 4cbef957f6 Changes the CMake compiler flags.
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.
2012-07-10 19:07:04 +00:00

62 lines
2.9 KiB
Plaintext

This file is here to allow devs to easily add stuff in the release notes for the next release, it allows easy syncing with the release team, since you don't have to be around when the release takes place...
Just dump whatever you want to have mentioned in the release notes here. Please take care that it is in a way that allows copy&paste to the release notes. That is making sure that spelling/grammar/whatever is usable and that you are using complete sentences, not just single words. Please do use forum syntax and do *NOT* split lines after 80 chars!
Stuff that belongs in here:
* groundbreaking changes (new campaigns, extremely new feature, ...)
* changed dependencies (new things, version bumps, stuff that was removed)
* known bugs
The release team should empty this file after each release.
=======
CHANGES
=======
[section="Removed Terrain"]
The old flowers on grassland terrain (Ggf) has been removed in favour of ^Efm, introduced during the 1.9 development series.
Maps containing the old terrain will no longer load.
[/section]
[section="Lua updated to 5.2"]
Lua interpreter was updated to 5.2
Some of the changes are not compatible, but still work due to the compatibility mode. The compatibility mode would be disabled after several minor releases, so it's best to rework the code according to http://www.lua.org/manual/5.2/manual.html#8
Some of the changes in interpreter are not compatible but don't have a compatibility mode.
[/section]
[section="CMake installation"]
Default man installation directory now confirms to FHS.
[/section]
[section="Clang defaults to strict compilation"]
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, please file bug reports if it breaks older versions of Clang.
[/section]
[section="Under the Burning Suns"]
The campaign Under the Burning Suns has had extensive code changes.
While most of them should not be visible, there are several changes that affect difficulty.
[list]
[*] The first tunnel collapse in scenario 6b, "In the Domain of the Dwarves", no longer kills both guards.
[*] The AI behaviour for the messenger in scenario 8, "Out of the Frying Pan", has been much improved.
[*] The chest at the end of the cave in scenario 8 now grants more gold on easy difficulties than hard and the amount will always take you to positive gold.
[*] There are scattered small changes that make the hardest difficulty slightly harder.
[/list]
Players are encouraged to try these scenarios and comment on its difficulty.
[/section]
[section="CMake compiler flags"]
The part to determine the CMake compiler flags has been rewritten and now has better support for compiler specific enabling of targets. Therefore it is recommended to regenerate your CMake build.
[/section]
[section="Another Change"]
[/section]
==========
KNOWN BUGS
==========
[list][*] Text for entry1.
[*] Text for entry2.
[/list]