The super tag dependency forms a directed graph. Boost Graph's depth first search implementation was used with a back edge detector to find the cycles.
This is a preparation for enumerating all keys that a tag can use, including the keys from the super tags. If cycles aren't handled, it is impossible to validate mandatory keys without entering an infinite loop.
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.
Version 13 of GCC added the -Wdangling-reference option, however
due to false positives it had to be moved from -Wall to -Wextra.
Discussion about its status in GCC-14 is in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110075
The warning is for C++ only and the flag will generate a warning
when compiling C files if the flag is set in Scon's CCFLAGS.
The docs don't explain exactly what triggers the warning, but here's the
explanation from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106393#c1
> The warning works by checking if a reference is initialized with a function
> that returns a reference, and at least one parameter of the function is a
> reference that is bound to a temporary. It assumes that such a function
> actually returns one of its arguments! ... suppress the warning when we've
> seen the definition of the function and we can say that it can return a
> variable with static storage duration.
Consistent with that, we're getting warnings on functions of the form
find(container, const std::string&). All of the things triggering it
seem to be false positives:
* Calls to find_widget<...>.
* Calls to theme::get_theme_config.
* Calls to race::gender_value.
* In src/actions/attack.cpp, any `attacker->attacks()[i]`.
Although there's an iterator in there, the eventual reference
is to a member of the array, not the iterator.
* In src/gui/dialogs/unit_advance.cpp, `cfg.child_range("...").back()`
That returns an object indirectly owned by cfg.
We'd like the other warnings of -Wextra, so turn off -Wdangling-reference.
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.
Turning GLIBCXX_ASSERTIONS adds some bounds checks, such as checking
in std::string::operator[]. It's a subset of the checks that GLIBCXX_DEBUG
adds, but has the advantage that it doesn't require a rebuild of the Boost
libraries.
None of the CI builds enable these assertions, as they slow down the code
which makes the unit tests time out.
msys2 pkg-config adds root system include path among -I flags and
passing it with -isystem isn't supported by gcc, and
the workaround of passing --dont-define-prefix to pkg-config doesn't
work on msys2's "subsystem" install of scons because posix style
absolute paths aren't handled properly when expanding CPPPATH.
Most likely related to https://github.com/msys2/MINGW-packages/issues/10761
In CMake this is the FORCE_COLOR_OUTPUT option. In SCons this is the
force_color option. They both pass -fdiagnostics-color=always to gcc,
or -fcolor-diagnostics to clang.
This is useful when building with Ninja, or running piped CI tools.
This is a more reliable way to detect distro with systemd support.
"systemd" binary may not be in PATH while systemctl would have to be.
This helps with part of issue #5692
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 also adds a few utility switches which people are probably already
familiarized with from the game proper. Most notably this means I don't
need to alter and recompile campaignd any time I want different logging
settings.
There's some functionality commented out in this commit while I figure
out how to wire it into the campaignd server class.
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.
Update the list of files installed by "scons install-pytools", dropping Python2
versions and adding their Python3 replacements. This doesn't update any
`import` statements, as the tools have already been ported to use the Python3
modules - the scons script was out of date and was still bundling the wrong
versions.
Note for anyone looking at the history - although most of the current
tools have a '3' in the name just to indicate that they're the Python 3 version,
there's a double-meaning to that number in wmlparser3.py's name. There was a
`wmlparser2.py`, where the `2` indicates a redesign of the original.
The data/tools/README.md file was renamed from plain README without being
converted to Markdown format. This commit touches about half of that file;
headings in that half are updated to be Markdown, but to reduce the diff the
other headings aren't updated.
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.
