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.
Comments on conflicts:
- llvm: d6f401e1 vs. 469ecc70 - docs for 6 and 7 say the default is
to build all targets, so we should be fine
- some pypi hashes: they were equivalent, just base16 vs. base32
This package contains several CMake files used for setting up its
provided tools for use in other projects build with CMake.
While packaging *ktouch* I found out that the ${_qt5Core_install_prefix}
variable doesn't expand at all, rendering the path to the `qmlcachegen`
binary useless. As a fix, the command itself is used instead of the path
to the binary.
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.
