blob: e6b4aec6938409bb3d59029d583a72a534cfe58a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
|
# -------------------------------------------------------------------
# Project file for the QtWebKit C++ APIs
#
# See 'Tools/qmake/README' for an overview of the build system
# -------------------------------------------------------------------
TEMPLATE = lib
TARGET = QtWebKit
WEBKIT_DESTDIR = $${ROOT_BUILD_DIR}/lib
# Use Qt5's module system
load(qt_build_config)
MODULE = webkit
MODULE_PRI = ../Tools/qmake/qt_webkit.pri
# ---------------- Custom developer-build handling -------------------
#
# The assumption for Qt developer builds is that the module file
# will be put into qtbase/mkspecs/modules, and the libraries into
# qtbase/lib, with rpath/install_name set to the Qt lib dir.
#
# For WebKit we don't want that behavior for the libraries, as we want
# them to be self-contained in the WebKit build dir.
#
CONFIG += force_independent
BASE_TARGET = $$TARGET
load(qt_module_config)
# Make sure the module config doesn't override our preferred build config.
debug_and_release:if(!debug|!release) {
# Removing debug_and_release causes issues with lib suffixes when building debug on Windows.
# Work around it by only removing build_all, and still create the Makefiles for both configurations.
win32*: CONFIG -= build_all
else: CONFIG -= debug_and_release
}
# Allow doing a debug-only build of WebKit (not supported by Qt)
macx:!debug_and_release:debug: TARGET = $$BASE_TARGET
# Make sure the install_name of the QtWebKit library point to webkit
macx {
# We do our own absolute path so that we can trick qmake into
# using the webkit build path instead of the Qt install path.
CONFIG -= absolute_library_soname
QMAKE_LFLAGS_SONAME = $$QMAKE_LFLAGS_SONAME$$WEBKIT_DESTDIR/
!debug_and_release|build_pass {
# We also have to make sure the install_name is correct when
# the library is installed.
change_install_name.depends = install_target
# The install rules generated by qmake for frameworks are busted in
# that both the debug and the release makefile copy QtWebKit.framework
# into the install dir, so whatever changes we did to the release library
# will get overwritten when the debug library is installed. We work around
# that by running install_name on both, for both configs.
change_install_name.commands = framework_dir=\$\$(dirname $(TARGETD)); \
for file in \$\$(ls $$[QT_INSTALL_LIBS]/\$\$framework_dir/$$BASE_TARGET*); do \
install_name_tool -id \$\$file \$\$file; \
done
default_install_target.target = install
default_install_target.depends += change_install_name
QMAKE_EXTRA_TARGETS += change_install_name default_install_target
}
}
WEBKIT += wtf
WEBKIT += javascriptcore
WEBKIT += webcore
!no_webkit2 {
WEBKIT += webkit2
# Ensure that changes to the WebKit1 and WebKit2 API will trigger a qmake of this
# file, which in turn runs syncqt to update the forwarding headers.
QMAKE_INTERNAL_INCLUDED_FILES *= WebKit2/Target.pri
QMAKE_INTERNAL_INCLUDED_FILES *= WebKit/WebKit1.pro
}
!no_webkit1: WEBKIT += webkit1
contains(DEFINES, WTF_USE_3D_GRAPHICS=1): WEBKIT += angle
qnx {
# see: https://bugs.webkit.org/show_bug.cgi?id=93460
# the gcc 4.4.2 used in the qnx bbndk cannot cope with
# the linkage step of libQtWebKit, adding a dummy .cpp
# file fixes this though - so do this here
dummyfile.target = dummy.cpp
dummyfile.commands = touch $$dummyfile.target
QMAKE_EXTRA_TARGETS += dummyfile
GENERATED_SOURCES += $$dummyfile.target
}
|
