Otherwise parts of the files might be compiled with different
optimization settings which a) isn't allowed when using pre-copmpiled
headers and b) isn't what we want anyway (safe for the one file we
need it for).
Even `-O1` causes compilation time & memory usage to skyrocket,
possibly exponentially, with the number of entries to `emplace_back()`
into the vector.
This isn't so bad with the current number of entries (489). In that
case compilation with `-O3` only takes 7.2s.
However, extending the list to cover ISO 639-3 means that the list
will include 7160 entries. With that many entries things are much,
much more severe:
• with `-O1` alone compilation takes 11m 23s already.
• with `-O3` memory usage exceeded 20 GB after six minutes when I had
to abort due to other running applications getting killed.
Runtime cost is negligible. I ran a micro benchmark. With all 7160
entries and no optimizations (`-O0`) the initialization takes ~1.4
milliseconds for the one-time initialization on startup; with
optimizations (`-O1`) it still took ~570 microseconds.
Part of the implementation of #3007.
The dark mode is only turned on if Windows 10's own dark mode is
enabled. This manual dark mode configuration is necessary as Qt itself
doesn't support Windows' dark mode yet; see the following bug:
https://bugreports.qt.io/browse/QTBUG-72028
This isn't a problem for other operating systems (Linux, macOS…) as Qt
uses the system colors there and will use dark colors when the
system's colors are set to dark colors, too.
Features include debuging, profiling, optimizations & sanitizers. The
flags don't depend on something that's actually tested, but only on
which features are enabled and which compiler & compiler version is
used. Therefore doing it in Ruby instead of sh is easier.
Actual warning:
lib/fmt/include/fmt/format.h:3475:55: warning: ISO C++ did not adopt string literal operator templates taking an argument pack of characters [-Wpedantic]
3475 | FMT_CONSTEXPR internal::udl_formatter<Char, CHARS...> operator""_format() {
| ^~~~~~~~
This has already been fixed in fmt's master branch.
Logic's more straight forward to implement there instead of having to
check in `configure`, adding a variable to `build-local.in` and using
that variable later on. The logic's the same in both places anyway.
According to issue #2508 a self-compiled version of `mkvextract`
misbehaves if the option `-fvisibility=hidden` is used. As building my
own DMG without the option works just fine, and as the resulting
programs work fine, too, I'll simply drop both flags from the build
process altogether.
Fixes#2508.