Qt requires access to the system ICU data due to its linking against
the system CoreFoundation and invoking CF APIs that tries to access it.
This manifests as a crash during build when it fails to access the data.
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
Previously fixed in 97904f8424
and #118084, but the fix was only applied to linux platforms.
This fixes libraries that depend on qtwebengine under darwin platforms.
This commit switches `libmysqlclient`-enablement from `!=null`-style
to `fooSupport`-style, by adding an additional boolean parameter `mysqlSupport`.
This parameter defaults to
`stdenv.hostPlatform==stdenv.buildPlatform`, so there should be no
change in behavior for the non-cross-compiling case.
Co-authored-by: Artturi <Artturin@artturin.com>
The fix-qt-builtin-paths.sh script replaces several strings in *.pr*
files with output names; for example
```
$$[QT_HOST_BINS] is replaced by $dev
```
This causes problems when cross-compiling: the `mkspecs/qconfig.pri`
in the `$dev` output of `qtbase` will have output names *of qtbase*
hardwired into it. Since `qmake` is part of the `qtbase` package,
it will pick up these hardcoded paths when compiling the other
modules.
As a result, the `installPhase` of `qtdeclarative` (and other
modules) will attempt to copy their results into the
already-registered store path for `qtbase`. This will fail, because
Nix prevents writes to a storepath after it has been registered.
Fortunately the `.pri` files understand environment variable
substitution: you can write `$$NIX_OUTPUT_DEV` to tell `qmake` that
it should use the value of the `NIX_OUTPUT_DEV` environment variable
*at `qmake`-run-time* (rather than at `qmake`-build-time).
The primary motivating example is openssl:
Before the change full package build took 1m54s minutes.
After the change full package build takes 59s.
About a 2x speedup.
The difference is visible because openssl builds hundreds of manpages
spawning a perl process per manual in `install` phase. Such a workload
is very easy to parallelize.
Another example would be `autotools`+`libtool` based build system where
install step requires relinking. The more binaries there are to relink
the more gain it will be to do it in parallel.
The change enables parallel installs by default only for buiilds that
already have parallel builds enabled. There is a high chance those build
systems already handle parallelism well but some packages will fail.
Consistently propagated the enableParallelBuilding to:
- cmake (enabled by default, similar to builds)
- ninja (set parallelism explicitly, don't rely on default)
- bmake (enable when requested)
- scons (enable when requested)
- meson (set parallelism explicitly, don't rely on default)
- waf (set parallelism explicitly, don't rely on default)
- qmake-4/5/6 (enable by default, similar to builds)
- xorg (always enable, similar to builds)
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
