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.
QT apps tend to call makeWrapper with a lot of arguments, which causes
noticable slowdowns (+100ms for app startup). The slow down boils down
to two reasons:
- the required string processing is O(N^2)
- bash is slow at doing the processing
By using the binary wrapper, we fix the second point, brining the
overhead down from 100ms to just 4ms or thereabouts.
I tested this change by rebuilding my whole system with it (I use
plasma). It booted and it works (that's where I type this commit
message), but I am not 100% sure if this won't break anything else.
Closes: #225871
