Original code from mesilliac in #6826. Made a separate PR for this since the relevant code moved to an entirely separate file and trying to "properly" fix the merge conflicts resulting from that isn't worth the time.
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 reverts commits 7ce1bf9f7d and c6a2dc9317.
OpenSSL >= 3.0 was required (but only when building with CMake) so that
src/preferences/credentials.cpp could use EVP_EncryptInit_ex2() (commit
a880f01a31), but that change was reverted (commit 83ab05532a), all
within three hours.
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.
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.
* 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.
