Due to an upstream change in vcpkg that breaks the simple integration previously available with `vcpkg integrate install`, building using that setup method is no longer possible. In order to work correctly, cmake must instead be used to generate the VS project files, since that is able to integrate with vcpkg, since vcpkg also uses cmake to build all the library dependencies.
An additional benefit of this is that it will no longer be necessary to separately update the VS project files since it will read the same source_lists files as cmake (on linux) and scons do.
This also enables running the WML unit tests on Windows with this in order to confirm that a valid wesnoth.exe is in fact being generated as well as fixes building the boost unit tests.
The warning level for both release and debug builds are now at level three, the remaining warnings have been fixed, and therefore strict builds have been enabled - any warning will now cause the build to fail, just like for the linux jobs.
Known issues:
* The boost unit tests don't actually run successfully - they fail on CI at least with an exit code on 201 - however I don't know if this is a real problem or just a problem with running headless on CI.
* The debug build doesn't quite work since the executables are built against the non-debug dlls but cmake copies over the debug dlls into the output directory. For now this can be worked around by copying the release dlls into the debug directory.
* The instructions in INSTALL.md are not very good since I don't use Windows and thus can't write anything more detailed. Ideally someone who uses Windows can add more detailed step by step instructions at some point.
Fixes#5741
This removes the build-time dependencies on SDL_ttf and FriBidi,
alongside the SDL_ttf wrappers, the SDL_ttf text surface class, the
SDL_ttf render cache, and the SDL_ttf (de)initialization code.
* Convert server_base class to use coroutine instead of handlers
* Rework wesnothd's client login to use coroutine
* Merge 3 player handling functions into a single coroutine
* update cmakelists too
* Implement send_doc_queued in terms of coroutine
* Use brace initialization for making asio buffers
* Implement campaignd's request handling in coroutine
* Brace-initialize entire vector
* Remove old handler based send/receive helpers
* Document coroutine send/receive helpers
* Made coro_send_doc() helper take wml doc by reference
In most cases there is no need to rely on shared pointers to ensure
object lifetime if using coroutines since even when coroutine is
suspended args are still kept alive by its context.
* Document coro_send_file()
* Silence deprecation warning to fix build on earlier versions of boost
* Explicitly check for boost.context to allow linking against static boost libs
* Add boost.coroutine to flatpak manifest
* Port winapi TransmitFile codepath to coroutines
* Exception safety fix
* Add boost.scope_exit to vcpkg
* Fix build with pre-1.66 boost
* Move coro_* helpers into server_base class
Those helpers were in .ipp solely because they were templated on handler
types, this is no longer true after coroutine based rework.
* Make server_base::coro_send_file non-inline
* CleanUp Xcode project
Co-authored-by: Martin Hrubý (hrubymar10) <hrubymar10@gmail.com>
The file only had a run-time effect if it listed any files as "fuzzy", which it
hasn't since the last change in 2015. However, that isn't a reason for removing
it.
The reason for removing it is that it doesn't make sense to automatically mark
images as fuzzy when an image changes, because fuzzy is often much better than
untranslated. This is different to the logic for strings, where a single word
can negate the meaning of a sentence. The decision has to be a manual process,
and at that point it might as well be done with the source-control tool's
delete-file function.
Even considering the previous times that l10n-track was used, I can't see a
scenario where it would be useful.
* Scenario: a screenshot needs to be replaced. In this case the new images are
going to be screenshots too. If the old images are out of date, better to
just delete them instead of needing the fuzzy mechanism; either option would
have the same effect of showing the up-to-date-but-untranslated image.
* Scenario: a map is completely redrawn. This seems unlikely, as a completely redrawn
image could be added as a new map rather than replacing the old one. Even if
it does happen, it's probably best to just delete the old --overlay.png
files.
* Scenario: a new landmark is added to a map. Using the existing overlay file
is still going to be good, as it means the rest of the map is shown
translated. There's surely new dialogue in the WML files commenting on this
new landmark, which would be a good place to say
# po: Lorem's Ipsum was added to the map on 24 Jan 2020, please add a label to your language's --overlay file.
* Scenario: an old feature is removed from the map. Using the existing overlay
will have an out-of-date label, and the significance of that would depend on
how it affects the storyline. This could be significant enough to make
showing the English labels be a better option than showing the translated
ones. However, the translated maps could be updated without knowledge of the
language, so if it's such a significant change then the developer writing the
new WML should probably do that.
* Scenario: a feature moves slightly on the map. This is an example where the
l10n-track file has been used, it happened with the Bitter Swamp on the
bottom-right corner of the title screen. I think it would have been better to
show the slightly-out-of-date overlay instead of showing the English.
Note about cherry-picking: in the 1.14 branch, the change needs to be applied
to src/picture.cpp instead of src/filesystem.cpp.
Reasoning being:
* The result_set and other APIs are nicer to use.
* We use mariadb on our server rather than mysql, so this would minimize the chance of any incompatibilities.
* The mysql C++ connector 1.1 isn't compatible with with c++17 (https://stackoverflow.com/q/47284705).
Certain distro/compiler combinations will apparently warn about not optimizing when _FORTIFY_SOURCE is set.
(cherry-picked from commit 09fcc6b0519d458cbc3e16788576000a8484020b)
As per sigurd's trial and error: RELRO's options are unknown entirely and -fstack-protector-strong results in compile errors. Building with just PIE and _FORTIFY_SOURCE enabled does then compile, but results in a broken executable.
(cherry-picked from commit c9541176776aeb676e99f1804d123552430582ee)
Use of this feature with GCC in particular causes the stack to become marked as executable.
(cherry-picked from commit 96b43a9af4ec76882afe6924e9c3dafb5b8beac5)
Scons OpenGL/GLEW test taken mostly verbatim from 3e2eba22a96cb2c6c69ee5109059b806f22a372f
(cherry-picked from commit 5e36a90039ddde3625690ace5259198e1932a7f8)
commit 3effecd added an "if" block in CMakeLists with a variable that
does not exist ("NLS"). This breaks running translation updates for
every cmake user. Changed the variable to the existing "ENABLE_NLS".
@Pentarctagon I don't know if the travis script has to be adjusted as
well. Please test.
(cherry-picked from commit 64fe3988d87b61e40199297d710c035d85dedd49)
Otherwise, if we build with sanitizers and optimizations, the sanitizer stacktraces can become quite hard to read.
(cherry-picked from commit 29089a47369c32d4eabb93ac7f5b33222c047670)
Travis now also makes use of this to set the optimization level for the -O0 builds, rather than extra_flags_*. This additionally fixes an issue where using -O0 in the release build with LTO resulted in the individual *.o files being compiled with -O0, but LTO then still linked with release's default -O3.
(cherry-picked from commit 63ff641662d4192401a49f9a002d7872000a3f02)
After some discussion, we concluded that this code was unmaintained, not even used in
some places (display.cpp, units/frame.cpp), leaving the only area that really used it
at all the image surface cache. Considering there was never really a conclusive benchmark
of its benefits and because said surface cache will be used a lot less going forward,
we're just removing it and simplifying everything for everyone.
Closes#1260 since it's now irrelevant.
(cherry-picked from commit 3792612fb759942e6eb5de51364c2cca4ed16b40)
Commit dfc42e8a8dd550ca04ae16e2d2d7ebffbba0bc21 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 4799ca05fe40838c41814433780d0464d9b8f071)
This reverts commit cdf9b465c668648721c4638ce117da130ad36284.
May this noise be my vengeance.
(cherry-picked from commit f6a128579ad6d94cc7c8a57bebd1fc2bb0f735a0)
Adds the CXX_STD variable which can be set. Currently defaults to 14. This also now makes cmake honor the CXXSTD env variable set on travis.
(cherry-picked from commit 983045718aa13a2b7b1b45bb37baa76a88a1d47e)
