0aa8dc3 converted to a runtime test and broke the scons SDL version check since
it only links which trivially makes it work for cross compilation though.
scons/lua.py makes use of the vestigial luadir option from commit
e94dcecf17.
Like FindLua.cmake, scons/lua.py searches for the Lua headers and
library, instead of using pkg-config like the old scons/lua.py (removed
in commit 9929d3ca1c) did, because even though distributions typically
provide .pc files for Lua, upstream Lua doesn't. It's likely that all
distributions that compile Lua as a C++ library will also provide .pc
files, but this check doesn't rely on that (just as the CMake module
doesn't).
Unfortunately, SCons.Conftest.CheckLib() prints up to eight messages
like "Checking for C++ library lua54-c++... no" until a working library
name is found.
Also conditionally include system Lua headers in src/lua/*.h and update
documentation in src/modules/lua_README.md, src/wesnoth_lua_config.h,
and src/wesnoth_lua_config.md. The two lines about "The primary commit,
after replacing the sources," in src/wesnoth_lua_config.md don't make
sense since the instructions were updated for submodule Lua in commit
d32cfb88c4 and make even less sense now with preceding commits for
updating CMake modules.
* 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 is workaround for windows style path confusing scons if they appear
in CPPATH etc. Paths without prefix still happen to be valid and they
start with "/", not "c:".
(cherry-picked from commit b347bc70b1)
With the change from SDL_mixer 2.0.1 to 2.0.2, we cannot simply check if SDL_mixer can open an OGG/Vorbis file, we must first open an audio device. [This is probably a mistake, since the documentation implies simply initializing the codec should be enough.] To avoid future problems, upgrade the feature-test program to perform a full initialization and shut-down; everything except actually playing the sound.
Closes#2137
This is needed because the CAIRO_STATUS_INVALID_SIZE constant was added in
that version.
1.10 is old enough that this change shouldn't cause problems for anyone.
For example, Debian Wheezy (2013) has Cairo 1.12.2.
SCons stupidly treats Clang as if it were GCC (hint: it's not) and that
causes the config check to fail due to the version symbols being
absent/not what we expect. So just ignore the GCC version when Clang is
detected, in the config test program; we can probably expect whoever is
using Clang to be able to deal with any issues that may arise from
attempting to use a Clang version we don't support.
As for why we don't test the Clang version number, according to
<http://clang.llvm.org/docs/LanguageExtensions.html#builtin-macros>,
"marketing version numbers should not be used to check for language
features, as different vendors use different numbering schemes." And
indeed, it is the case with the versions of Clang shipped with XCode
that they do not accurately reflect the upstream version they correspond
to and have weird version numbers such as 5 (as of this writing upstrema
hasn't even released version 4.0 yet). Such is life.
