The resource file has reached a size at which the C++ compiler
exhausts available virtual memory on some 32-bit architectures.
On Windows & macOS the GUI will look for the file in
`<folder_with_executables>/data/qt_resources.rcc`, and in the
directory set with `configure`'s `--datadir` parameter on other
systems (which usually means `/usr/share/mkvtoolnix`). The `install`
build system commands installs it into that folder.
gcc's implementation of the C++17 file system library doesn't support
UNC paths of style `\\?\…` on Windows. There doesn't seem to be any
progress towards implementing support for it.
Fixes#3058. See also #2916.
Newer libFLAC in MXE require a preprocessor definition of
`FLAC__NO_DLL` to signal that libFLAC wasn't built as a DLL. Otherwise
the linker will look for the wrong symbol names.
The prior method was to generate one line of
`g_container.emplace_back(…)` per entry in the list & letting the
compiler chew on that. Each string argument in that call was done was
`u8"Some Name"s`, meaning as a std::string instance.
Drawbacks:
• takes the compiler ages to compile, even forcing me to drop all
optimizations for the ISO-639 language list file
• even smaller files such as the IANA language subtag registry lists
take more than 30s to compile
• due to no optimizations initialization is actually not as fast as
could be
The new method uses a plain C-style array of structs with `char
const *` entries for the initial list. The initialization method then
copies the entries from that list to the actual container, again using
`std::emplace_back(…)`.
This yields sub-1s compilation times even with the longest file, the
ISO-639 language list, and the runtime initialization is actually
faster.
For some stupid reason plain old rake doesn't parallelize task
execution properly (at all?) if there's only one top level
target (e.g. "default"), no matter how high `-j` is set to. drake does
much better.
This is in preparation of fixing #3137. The plan is not to use
libfile's MIME type detection but Qt's. As both mkvmerge and the GUI
need to auto-detect the MIME type, this means that the command line
applications will have to be linked against Qt's core library (but not
the GUI libraries).
This is in preparation of fixing #3137. The plan is not to use
libfile's MIME type detection but Qt's. As both mkvmerge and the GUI
need to auto-detect the MIME type, this means that the command line
applications will have to be linked against Qt's core library (but not
the GUI libraries).
Currently this still requires patching `build-config` after having run
`configure` and providing the correct values for `QT_CFLAGS`/`QT_LIBS`
manually.
Part of the implementation of #3115.
The old regular expression did not filter out non-numeric optimization
levels options such as `-Os`, nor did it filter the option out if it
was at the end of the flags string.
See 3105 for context.
