On macOS the default `xsltproc` installation has the same limit (3000)
as on Linux, but for some reason it exceeds that limit on
macOS. Bumping it to 10000 lets builds succeed on macOS, too.
Fixes#2754.
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.
The internal libEBML was updated to v1.3.9. That version contains
changes to cmake to build an additional header file, ebml_export.h. In
MKVToolNix, which isn't cmake-based, that file has to be created
manually, and the Rakefile does so.
However, when configure runs the file doesn't exist yet. This means
that any attempt to compile a test program with the internal libebml
will fail due to the header not being found. configure's compilation
checks will therefore fail.
For the detection of libebml::FindNextChild doing a compilation check
against the internal libebml isn't really needed as we know that the
version does include it. So just hardcode that knowledge and avoid the
compilation check.
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.
This method works for systems where a logind-compatible D-Bus
interface is available for inhibiting sleep & idle states. Requires
Qt's D-Bus library.
Part of the implementation of #2411.
nlohmann's JSON libraries in version 2.x used to strip bytes that
aren't valid UTF-8 from strings (e.g. service/station names in MPEG
transport streams) before outputting the JSON data structures. With
MKVToolNix v24 that bundled library was updated to v3 which now throws
an exception on such invalid data.
Therefore mkvmerge now takes care of replacing invalid bytes with
placeholder characters itself before passing the strings to nlohmann's
JSON library.
Fixes#2327.
Recent `qmake` versions warn about plugins being added multiple times
via the `QT_PLUGIN` setting. However, our configure must add the
plugins manually as it cannot rely on them being present automatically
in older Qt versions. So just ignore those warnings.
Messages that are silenced are ones such as this:
> Your input po file ./doc/man/po4a/po/ja.po seems outdated (The
> amount of entries differ between files: 958 is not 633). Please
> consider running po4a-updatepo to refresh it.
Older versions suffered from issues such as segmentation faults on
startup with optimization levels higher than `-O2` or with
`-fipa-icf`. v7.2.0 is OK, though.
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
