The previous code using substituteInPlace was broken for both 5.9 and
5.11 (latter was broken after a minor release bump). Using patches
should make things fail loudly and prevent modules/qtwebengine.nix from
being littered with version checks.
The patch for 5.12 is only tested to apply.
QtWebEngine's build system is setup to perform certain platform checks
(see mkspecs/features/platform.prf). But a failed check will not cause
configuration phase to fail, but instead it configures no build targets.
So in such case the build will successfully perform build and install
phases. An empty output directories will are produced and the build
succeeds.
This patches qtwebengine qmake files to properly fail during
configuration phase.
This doesn't touch qt56 as it doesn't have this mechanism.
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_NSData", referenced from:
objc-class-ref in qmacfunctions.o
"_OBJC_CLASS_$_NSMutableArray", referenced from:
objc-class-ref in qmactoolbar.o
objc-class-ref in qmactoolbardelegate.o
ld: symbol(s) not found for architecture x86_64
b785d4813e introduced breakage in Qt
modules for 5.6 and 5.9, especially visible is Qt Webkit.
This was manifested by having a non-sensical build log where it is using
the top-level `src` attribute as source instead of Qt Webkit's own
source.
Were it not for the `src` top-level attribute (which is a legit
package), the error would have been made obvious by passing `null` to
`src`.
This partily reverts newly introduced way `src` can be passed to a
qtModule, instead relying on extending the `srcs` attrset.
For ZHF #45960
We use MACOSX_DEPLOYMENT_TARGET=10.10 in nixpkgs and some darwin
packages like CoreFoundation are based on the 10.10 sources from
opensource.apple.com.
This is the first time since 5.9 that we also update `qtwebkit`.
`qtwebkit` is not maintained by Qt anymore and thus, we switch to the
community port as for example arch has done. To prevent pulling in
single patches, we just stick to the latest git version.
