This is a complement to #7416 where it replaces opening the replay's download URL in a browser with directly downloading it into the player's save folder.
* the FindSDL2 module forwards to CONFIG mode first
* if that fails (eg. no -version.cmake or config not even present) it
uses pkg-config
* exports SDL2::SDL2 and SDL2::SDL2main as targets
* fix missing IMPORTED_LOCATION for other build types in Vorbisfile
Also moved boost and openssl to using the "import targets" (ie: https://cmake.org/cmake/help/latest/module/FindBoost.html#imported-targets) which are apparently the modern way to use cmake. Many of the other libraries don't support that however, and SDL is only fully(?) supported using this as of cmake 3.19.
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>
This has been added as a submodule for convenience of use, since mariadbpp isn't included in any repositories (linux distros, vcpkg, etc) aside from an Arch AUR.
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).
