69cf5181c3
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)
22 lines
463 B
Bash
22 lines
463 B
Bash
qmakeConfigurePhase() {
|
|
runHook preConfigure
|
|
|
|
$QMAKE PREFIX=$out $qmakeFlags
|
|
|
|
if ! [[ -v enableParallelBuilding ]]; then
|
|
enableParallelBuilding=1
|
|
echo "qmake4Hook: enabled parallel building"
|
|
fi
|
|
|
|
if ! [[ -v enableParallelInstalling ]]; then
|
|
enableParallelInstalling=1
|
|
echo "qmake: enabled parallel installing"
|
|
fi
|
|
|
|
runHook postConfigure
|
|
}
|
|
|
|
export QMAKE=@qt4@/bin/qmake
|
|
|
|
configurePhase=qmakeConfigurePhase
|