Older versions suffered from excessive memory usage with optimization
levels higher than `-O1`:
%https://bugs.llvm.org/show_bug.cgi?id=11962
v3.8.0 is known to be OK, though.
`clang++ -dumpversion` always outputs 4.2.1 as it was designed to be
compatible with `g++` in that version. So parse `clang++ --version`
for `clang++` instead.
libEBML v1.3.5 contains the following change:
------------------------------------------------------------
EbmlMaster::CheckMandatory: only fail for default-value-less mandatory elements
The function EbmlMaster::CheckMandatory() will now only return false
if a mandatory element is missing for which there's no default value
in the specifications. This means that callers such as
EbmlMaster::UpdateSize() and by extension EbmlMaster::Render() will
not insist on all mandatory elements being present anymore, but only
those for which there's no default value.
------------------------------------------------------------
This allows mkvmerge, mkvpropedit and the GUI's header editor to only
actually add those elements that have to be added to a master before
writing it to the file. Adding e.g. the TrackLanguage element isn't
necessary anymore if should be set to "eng" anyway as "eng" is its
default value. Before the change libEBML was insisting on it being
present in the "TrackEntry" master, though, no matter what it was set
to.
The upstream project intends the include files to be installed in
`$includedir/nlohmann/json.hpp`,
e.g. `/usr/include/nlohmann/json.hpp`. Debian did not follow that
recommendation and installed them directly in `$includedir`. Therefore
`configure` was only looking for the latter, not the former.
However, Debian will soon follow suit. Therefore detection has been
extended to check for the intended location first.
Fixes#2048.
Earlier versions fail to build on both my development system as well
as my CentOS 7 BuildBot CI instance. Therefore I cannot properly
support that version anymore.
See #2037.
This changes several things:
1. The path to the plugins is no longer determined by looking through
the include flags in QT_LIBS. This process was broken for paths
with file names. Instead, qmake is queried for the installation
location for the plugins.
2. Similar to qmake, configure now generates a file for both mkvinfo
and mkvtoolnix-gui that includes the appropriate #include
directives for the chosen plugins. Therefore no additional #ifdef…
logic is required for the static plugins in other parts of the two
programs.
3. For platforms other than Windows or macOS, configure will now add
the Xcb platform integration plugin. This is required for using a
static Qt on Linux. This change should implement #1898.
The source will start using the following features from the C++14
standard:
• the "std::make_unique()" Standard Library function
• digit separators
• binary literals
• generic lambdas
gcc's v4.9.x and clang's v3.4 are the oldest releases to support all of
them.
The GUI will now cache file identification results on disc. When the
same file is identified a second time the cached results are used
instead leading to a huge speed gain, especially when scanning Blu-ray
playlists multiple times.
Both positive and negative results are cached.
Cache results are invalidated whenever one of the following conditions
is met:
• if the source file's modification time stamp differs from when the
result was cached
• if the source file's size in bytes differs from when the result was
cached
• if the current version of MKVToolNix GUI differs from the version used
to write the cached result
Newer versions of Qt (definitely 5.7.0 but not yet 5.5.1) contain part
of the platform-specific code not in e.g. libqwindows.a but in
libQt5PlatformSupport.a. That library doesn't seem to be mentioned in
the LDFLAGS gathered from pkg-config. But its functionality is actually
required for libqwindows.a.
Therefore look for the library manually and link it if it's found.
Required in at least the static mingw cross-compiled build.
Normally configure uses pkg-config for detecting Qt and setting
QT_CFLAGS and QT_LIBS. With this option configure won't use pkg-config
and rely on the user having set both variables before running
configure. This enables using Qt on systems where no pkg-config files
are generated (e.g. Qt 5.6.0 on MacOS with frameworks enabled).
See https://github.com/Homebrew/homebrew/pull/50234
