Bug 94914 - [Qt] WebKit fails to detect QtQuick2 if Qt is built with -prefix
Summary: [Qt] WebKit fails to detect QtQuick2 if Qt is built with -prefix
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Tor Arne Vestbø
Depends on:
Blocks: 76773
  Show dependency treegraph
Reported: 2012-08-24 01:51 PDT by Simon Hausmann
Modified: 2012-09-11 10:56 PDT (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Simon Hausmann 2012-08-24 01:51:41 PDT
In a top-level Qt build, a .qmake.super file provides QMAKEMODULES += /path/to/modules/mkspecs lines that allow qmake to locate other Qt modules prior to their installation to the target prefix, allowing for example WebKit to link compile and link against QtQuick2.

When build-webkit calls qmake on configure.pro to detect modules and system features, qmake is invoked with -nocache, which disables the reading of the .qmake.super file and therefore results in WebKit failing to detect the presense of QtQuick2 and other modules.

One possible solution would be to manually remove the .qmake.cache file that the -nocache parameter tries to circumvent prior to calling qmake on configure.pro, another solution would be to get rid of this step altogether and always use configure.pro from within the top-level WebKit.pro.
Comment 1 Simon Hausmann 2012-08-24 01:55:17 PDT
It seems to me that removing the extra call to qmake -nocache configure.pro from build-wekbit would be the preferred solution.

I wonder how that would look like in practice, including the elimintation of .webkit.config. How do we detect that the defines changed and that we need a clean build?
Comment 2 Simon Hausmann 2012-08-24 01:58:13 PDT
CC'ing Ossy as this may possibly affect the bot operations, depending on the solution.
Comment 3 Csaba Osztrogonác 2012-08-24 05:49:10 PDT
I don't know too much about these feature detection things 
inside Qt, Tor Arne and Ossi are better choice. :)

But we should preserve this quick/full-incremental/clean build feature
somehow, it is the one of the most useful thing in our build system.

Triggering clean build on the bots manually because of a changed 
define day by day was terrible. I don't want to do it again. :)

If there isn't better solution, can't we differentiate somehow the 
standalone WebKit builds (developer build) and the top-level Qt builds?
Comment 4 Tor Arne Vestbø 2012-09-04 10:10:01 PDT
Comment 5 Simon Hausmann 2012-09-11 10:56:51 PDT
Committed r128174: <http://trac.webkit.org/changeset/128174>