Subprojects are only present to provide dependencies when the
local package manager is unable to provide the libraries.
Because fixing dependencies (and by extensions warnings) is out
of scope of staging (ie: such as SDL warnings), so too are
warnings from subprojects. Therefore, seeing excessive warnings
from a subproject only acts as confusing and excessive visual
clutter.
If someone does want to see greater subproject warning levels,
they can easily be "turned up" with:
-Dmt32emu:warning_level=3
-Dfluidsynth:warning_level=3
GCC 7 and 8 were released before the std::filesystem specification
was finalized in C++17, and use "experimental/filesystem" as
their include file and "std::experimental::filesystem" as the
namespace.
Newer GCC's and other compilers (Clang, MSVC) are currently
modern enough that no workarounds are needed for them.
Therefore, this commit uses a temporary "std_filesystem.h" that
normalizes these differences and provides a "std_fs" namespace.
The std_prefix was selected to explicitly indicate that the
file and namespace comes from std::, and not our own creation.
Unfortuantely we also cannot use the commonly suggested "fs::"
namespace shorthand due to the CPU core using an "fs" enum value.
When GCC 7 and 8 are eventually not supported, we can mass replace
"std_filesystem.h" and "std_fs::" with their C++17 equivalents,
<filesystem> and std::filesystem, respectively.
Inject build instructions via dependency, just like other bundled libraries.
Also, move dependency declarations of bundled libraries to their
respective meson files.
Since we upgraded to meson > 0.53, we can use summary to highlight some
information important during build. This is way more readable than using
message function for the same purpose.
Why do we want this?
Currently sdlmain has three code branches that are only active
when the code is compiled with SDL versions prior to 2.0.5.
Testing these pre-2.0.5 branches is difficult because it
requires installing obscure OSes and/or installing end-of-like
operating OSes. We also have no maintainers running such
operating systems nor can we expect this of current and future
maintainers.
Repology shows that the currently maintained operating systems
are using SDL2 2.0.5 and greater:
macOS:
- Brew 2.0.14
- MacPorts: 2.0.14
Linux:
- Arch (rolling distro): 2.0.14
- CentOS 7 (aarch64, x86-64: 2.0.10 and 2.0.14
- Cygwin: 2.0.7
- Debian (old-stable): 2.0.5
- Devuan 2.0 (oldest non-EOL release): 2.0.5
- Fedora 33 (oldest non-EOL release): 2.0.14
- FreeBSD ports: 2.0.14
- Gentoo: 2.0.14
- Manjero stable: 2.0.14
- MSYS2: 2.0.14
- OpenBSD: 2.0.14
- OpenSUSE Leap 15.2 (oldest non-EOL release): 2.0.8
- Raspbian (old-stable): 2.0.5
- Rocky Linux 8 (CentOS fork): 2.0.10
- Ubuntu 18.04 (oldest non-EOL release): 2.0.8
Windows:
- vcpkg: 2.0.14
The only operating systems that _are_ maintained but don't support
support SDL2 2.0.5 are:
- Salix 14.2 (released in 2014): 2.0.4
- Trisquel 8.0 (EOL in "2021", month/day unspecified): 2.0.4
Ref: https://repology.org/project/sdl2/versions
Default .conf file name after this change is:
- dosbox-staging.conf - for buildtypes release, plain, and other
non-debug build types
- dosbox-staging-git.conf - for buildtype debug and debugoptimized
It does not work for Visual Studio buildsystem, but we're distributing
these builds ourselves, so simple adjustment on CI is enough (this tiny
hack will disappear once VS buildsystem will be replaced with Meson
anyway).
Pros of implementing this change:
- It's easier to test Linux and macOS builds before the release
- Removes another step from our release checklist (!)
- Makes life easier for packagers, who want to deliver pre-release
builds (e.g. preparing new package or providing weekly test builds)
Cons of implementing this change:
- Users testing our official snapshot builds might end up with broken
default .conf file for next stable release.
The pre-scalar:
1. Is read and applied to the samples before limiting in
SoftLimiter
2. Is written-to and updated when the user updates their
channel's mixer level.
These two tasks can occur in separate threads, therefore
a potential data-race exists on the pre-scalar value as
reported by Clang's thread sanitizer:
1. When applying the scalar:
ThreadSanitizer: data race
../src/misc/soft_limiter.cpp:194 in void
SoftLimiter::ScaleOrCopy<(signed
char)0>(std::vector<float, std::allocator<float> > const&,
unsigned short, float, __gnu_cxx::__normal_iterator<float
const*, std::vector<float, std::allocator<float> > >,
__gnu_cxx::__normal_iterator<float const*,
std::vector<float, std::allocator<float> > >, float,
float, std::vector<short, std::allocator<short> >&)
2. When updating the scalar via mixer callback:
ThreadSanitizer: data race ../src/midi/midi_mt32.cpp:362
in MidiHandler_mt32::SetMixerLevel(AudioFrame const&)
Vorbis has been deprecated for years by its maintainer Xiph who
recommends Opus as its successor because it provides:
- superior audio qualilty at lower bitrates
- PCM-accurate seeking
- very low block-level latency
One of the reasons Staging supports Opus is to allow those
packaging games (like GoG) to finally get off Vorbis once and
for all.
However, if Staging makes Opus optional for package maintainers
then why would anyone packaging games rely on Opus.
This commit make Opus no longer optional. We know Opus is supported
under all known repositories that we ever expect Staging to run on,
and even beyond that we know Opus can be compiled on all platforms
as well.
Old implementation of NE2000 depends on pcap library, which we don't
want to use; disable the feature for now to make it possible to import
patches replacing libpcap with libslirp.
Convert option try_sdl2_static into a new one, where user can select
several libraries that will be marked for static linking.
Provide short explanation in meson_options.txt file.
- We use "not found message" for dependencies, which was introduced in
0.50.0. Our meson script was still operational on 0.49.0, but it
was generating warnings. Usage of this feature combined with minimum
meson version was generating warnings for everyone else as well.
Rising minimum version avoids any confusion about what's the problem
when.
- Meson version 0.51.0 has important bugfix; rising minimum version
forces packagers into using client where this problem does not need
to be re-discovered or worked around. Consequently, we can remove
the assert now.
When comparing to default meson versions in various repos:
- Fedora, Arch have up-to-date Meson.
- Debian Stable is on 0.49.0, but Testing has newer version already and
new Stable release in only a few months away.
- Ubuntu 18.04 LTS uses outdated Meson version, older than 0.49.0 already.
- Ubuntu 20.04 LTS uses Meson 0.53.0, so we're clear there.
- Other OSes generally have newer Meson versions.
Upstream SVN r4424 started refactorization of cpu module, and it breaks
those backends; to be re-enabled once refactorization is done or when
we'll have time to fix it ourselves.
Simplify meson version check; we don't need an assert when minimum
version check is built straight into the project function (so the
version is verified in older meson clients as well).
Add license field.
This change BREAKS Autoconf-based buildsystem. Only Meson and Visual
Studio buildsystems are operational from this point forward.
Thanks to this change, it will be easier for developers and testers to
communicate/detect the exact version of emulator.
Builds created from tarball releases OR builds from Git repo
checked out to point to an annotated tag will behave this way:
$ dosbox --version
dosbox (dosbox-staging), version 0.77.0
...
Development builds from Git repo will behave this way:
$ dosbox --version
dosbox (dosbox-staging), version 0.77.0-alpha-457-g6d8d10a9
...
Meson handles this "automagically", correctly for us via vcs_tag
function. We use it to generate version.cpp file - this way new commits
in repo will rebuild only a single file and trigger linker, but will
never result in full rebuild.
When Meson cannot obtain info version from Git, it automatically falls
back to version specified in our project function on top of meson.build
file.
Leave VERSION macro in place (it originated from Autoconf) in several
places - it's being extensively used when communicating e.g. "emulated
modem firmware version" and other fake-hardware identification.
Any builds created with Visual Studio (Release and Debug builds) will
use hardcoded version string for VERSION macro and hardcoded version
string DOSBOX_DETAILED_VERSION for all the places where we want more
info. This macro defaults to string "git" and is being overriden with
output of "git describe" on CI.
Also, adjust --version copyright message for readability and to better
fit into 80 colums.
Fixes: #543
Add new option (use_mt32emu), to allow users to opt-out of this
dependency if necessary. Aside of Meson WrapDB fallback, treat it as any
other dependency.
As of early 2021, meson 0.49.x is packaged by Debian Stable and almost
all other up-to-date repositories.
Notably, it's missing from Ubuntu 18.04 (which uses meson 0.45.2).
We try to keep the compatibility with older meson versions to have wide
support amongst Linux distributions, but it means some improvements need
to wait until newer meson is widely available.
