Prevents using the system qmake6 in cross-compilation situations.
Also cleans up the paths to `lconvert`, `moc`, `rcc` and `uic` from
the Qt 6 detection so that Qt 5 can detect their own version.
Part of the implementation of #3115.
Qt 6
`configure` will look for Qt 6 first and only continue looking for Qt
5 if Qt 6 isn't found or disabled via `--disable-qt6`.
Qt 6 detection works by first looking for the `qmake6` binary. Its location
can be specified with the `--with-qmake6=…` option.
All other Qt 6 related facts (such as compiler & linker flags or the
position of the other required tools such as `lconvert`, `moc`, `rcc` and
`uic`) will be derived from the output generated by `qmake6`.
Note that at this point Qt 6 is not yet supported for the cross-compilation
build to Windows, nor is a static Qt 6 build supported yet.
Note that the command line options `--enable-static-qt`,
`--with-qt-pkg-config-modules` and `--without-qt-pkg-config` only apply to
the Qt 5 and have no effect on Qt 6.
Qt 5
The options for specifying the position of the tools (`--with-moc=…`,
`--with-rcc=…` and `--with-uic=…`) have been removed. Their position
will now be derived from the output generated by `qmake`.
General
Completely disabling the GUI now requires passing both `--disable-qt6`
and `--disable-qt` options.
Part of the implementation of #3115.
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.
