[Qt] Reduce memory pressure at link time with less compromise on speed of linking

Reviewed by Csaba Osztrogonác.

Revert r131718 that made us pass -fno-keep-memory to the linker for any
i386 builds. The downside of passing that option is that it slows down
the process of linking and as Ossy determined, release builds do _not_
take as much memory (2.x GB) for linking but much less (~350MB).

However there is one condition where even release builds do take up too
much memory, and that is when Qt is configured with
-separate-debug-info, because it adds a -g next to -O2. The recent
introduction of loading qt_build_config enabled us to read qmodule.pri,
which adds the -g if Qt is configured with -separate-debug-info. So
instead of playing with -fno-keep-memory (which is a last resort
measure for debug builds) we should tweak our existing mechanism of
dealing with the debug info:

production_build.prf tries to ensure that we use -g only in static
libraries that contain API facing code, so that we get nice backtraces
at least into the API layer. For other static libraries such as WebCore
we skip -g via CONFIG += no_debug_info. One of the conditions for
enabling this tweak is CONFIG(debug, debug|release). This patch adds
contains(QT_CONFIG,separate_debug_info) to the conditions.

The patch also extend the CONFIG += no_debug_info part with the removal
of no_separate_debug_info. There is no point in running an extra
build step to strip out debug info into a separate file if at the same
time we tell the compiler to not generate any debug info altogether.

* qmake/mkspecs/features/production_build.prf:
* qmake/mkspecs/features/unix/default_post.prf:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131728 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Don't use the C API internally in WebKitHitTestResult
https://bugs.webkit.org/show_bug.cgi?id=96779

Reviewed by Xan Lopez.

Using the C++ classes directly instead of the C API wrappers we
avoid a lot of toImpl/toAPI casts, string conversions and
allocations. The code is also a lot simpler and easier to read.

* UIProcess/API/gtk/WebKitHitTestResult.cpp:
(webkitHitTestResultCreate):
(webkitHitTestResultCompare):
* UIProcess/API/gtk/WebKitHitTestResultPrivate.h:
* UIProcess/API/gtk/WebKitWebView.cpp:
(webkitWebViewMouseTargetChanged):
(webkitWebViewPopulateContextMenu):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131729 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, do not make UseV8.cmake executable.

* UseV8.cmake: Removed property svn:executable.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131730 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Don't use the C API internally in PolicyClient classes
https://bugs.webkit.org/show_bug.cgi?id=96781

Reviewed by Xan Lopez.

Using the C++ classes directly instead of the C API wrappers we
avoid a lot of toImpl/toAPI casts, string conversions and
allocations. The code is also a lot simpler and easier to read.

* UIProcess/API/gtk/WebKitNavigationPolicyDecision.cpp:
(webkitNavigationPolicyDecisionCreate):
* UIProcess/API/gtk/WebKitNavigationPolicyDecisionPrivate.h:
* UIProcess/API/gtk/WebKitPolicyClient.cpp:
(decidePolicyForNavigationActionCallback):
(decidePolicyForNewWindowActionCallback):
(decidePolicyForResponseCallback):
(attachPolicyClientToView):
* UIProcess/API/gtk/WebKitPolicyClient.h:
* UIProcess/API/gtk/WebKitPolicyDecision.cpp:
(_WebKitPolicyDecisionPrivate):
(webkitPolicyDecisionFinalize):
(webkitPolicyDecisionSetListener):
(webkit_policy_decision_use):
(webkit_policy_decision_ignore):
(webkit_policy_decision_download):
* UIProcess/API/gtk/WebKitPolicyDecisionPrivate.h:
* UIProcess/API/gtk/WebKitPrivate.cpp:
(wkEventMouseButtonToWebKitMouseButton):
* UIProcess/API/gtk/WebKitPrivate.h:
* UIProcess/API/gtk/WebKitResponsePolicyDecision.cpp:
(webkitResponsePolicyDecisionCreate):
* UIProcess/API/gtk/WebKitResponsePolicyDecisionPrivate.h:
* UIProcess/API/gtk/WebKitWebView.cpp:
(webkitWebViewConstructed):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131731 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Don't use the C API internally in WebKitURIResponse
https://bugs.webkit.org/show_bug.cgi?id=96782

Reviewed by Xan Lopez.

Using the C++ classes directly instead of the C API wrappers we
avoid a lot of toImpl/toAPI casts, string conversions and
allocations. The code is also a lot simpler and easier to read.

* UIProcess/API/gtk/WebKitURIResponse.cpp:
(webkitURIResponseSetCertificateInfo):
* UIProcess/API/gtk/WebKitURIResponsePrivate.h:
* UIProcess/API/gtk/WebKitWebView.cpp:
(setCertificateToMainResource):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131732 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Don't use the C API internally in WebKitWebResource
https://bugs.webkit.org/show_bug.cgi?id=96783

Reviewed by Xan Lopez.

Using the C++ classes directly instead of the C API wrappers we
avoid a lot of toImpl/toAPI casts, string conversions and
allocations. The code is also a lot simpler and easier to read.

* UIProcess/API/gtk/WebKitWebResource.cpp:
(_WebKitWebResourcePrivate):
(webkitWebResourceCreate):
(webkitWebResourceGetFrame):
(ResourceGetDataAsyncData):
(resourceDataCallback):
(webkit_web_resource_get_data):
(webkit_web_resource_get_data_finish):
* UIProcess/API/gtk/WebKitWebResourcePrivate.h:
* UIProcess/API/gtk/WebKitWebView.cpp:
(setCertificateToMainResource):
(webkitWebViewResourceLoadStarted):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131733 268f45cc-cd09-0410-ab3c-d52691b4dbfc