Qt is smart enough to figure out the target Qt version for native plugins.
However, Qt is _not_ smart enough to figure out the target Qt version for
QML imports, which causes all kinds of funny breakage when you start running
Qt 5 applications from Qt 6 ones and vice versa.
So, do some minimally invasive surgery to make different Qt versions pick up
different QML import path variables, so they don't mess with each other.
This is kind of very cursed, but what can you do.
The version of Chromium used by Qt WebEngine 5.15.x does not build with
clang 16 due to the following errors:
* -Wenum-constexpr-conversion: This is a downgradable error in clang 16,
but it is planned to be made into a hard error in a future version of
clang. Patches are not available for the version of v8 used by
Chromium in Qt WebEngine, and fixing the code is non-trivial.
* -Wincompatible-function-pointer-types: This is also a downgradable
error generated starting with clang 16. Patches are available upstream
that can be backported.
Because the first error is non-trivial to fix and suppressing it risks
future breakage, clang is pinned to clang 15, which also makes fixing
the incompatible function pointer conversion errors unnecessary.
The derivation is also updated to use the `overrideLibcxx` adapter.
Using it links qt5.qtwebengine against the same versions of libc++ and
libc++abi as qt5.qtbase even though they are built with different
versions of clang, avoiding the compatibility problems that can cause.
Also, reenable x86_64-darwin because it builds successfully too.
Our qutebrowser package has been vandalized by various commits, such
as c9cc3a2e3e and
ad0bbaf1d2, which made erroneous
assertions such as "since qutebrowser 3.0.0 the derivation is only
building for qt6."
This commit repairs the vandalism.
This commit fixes builds of `pkgsCross.*.qt5.qtbase` by:
- Adding the buildPlatform compiler to depsBuildBuild in qtbase.nix
and qtModule.nix. The `qtbase` build machinery expects to find it
in the $PATH in unprefixed form.
- Setting the `PKG_CONFIG_SYSROOT_DIR` and `PKG_CONFIG_LIBDIR`
environment variables when compiling a cross-targeted `qmake`.
This is required; if these environment variables are unset,
`qmake` won't even try to use `pkg-config`.
- Adding the `-device` and `-device-option` flags necessary for
cross compilation to `configureFlags`.
- Adding the (one-entry at the moment) Rosetta Stone for QT-5 as a
`let`-defined `qtPlatform` function which takes a nixpkgs platform
and returns a QT-5 `mkspecs`-string.
Co-authored-by: Christoph Neidahl <christoph.neidahl@gmail.com>
Qt loads its own translations from a hardcoded path, and those are used
(among other things) for determining RTL layout preferences in applications,
so they are definitely something we want to have.
This adds a qtbase/qttools rebuild to the chain, but it's fast enough that it's
probably fine.
Another approach would be to load translation paths from the environment,
and inject it in wrapQtAppsHook, but that seems like more complexity
for very questionable build time savings.
This is kind of experimental, and we decided after a conversation
with upstream to keep it vendored for a bit and then upstream if
nothing explodes.
666ce51d4e
Nix builds of QTWebEngine doesn't support sound output via Pulse, only
through ALSA, unless sandboxing is disabled and LD_LIBRARY_PATH
contains a reference to the Pulse libraries.
By default, Chromium won't link to PulseAudio, but dlopens it in
run-time. It is tricky to make this work because of the nontrivial
sandbox configuration. Nix builds of Chromium already link against
Pulse directly, so it makes sense to copy this behavior in
QTWebEngine.
Deeply-curried functions are pretty error-prone in untyped languages
like Nix. This is a particularly bad case because
`top-level/splice.nix` *also* declares a makeScopeWithSplicing, but
it takes *two fewer arguments*.
Let's switch to attrset-passing form, to provide some minimal level
of sanity-checking.
