RESOLVED FIXED 94914
[Qt] WebKit fails to detect QtQuick2 if Qt is built with -prefix 
https://bugs.webkit.org/show_bug.cgi?id=94914
Summary [Qt] WebKit fails to detect QtQuick2 if Qt is built with -prefix
Simon Hausmann
Reported 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.
Attachments
Add attachment proposed patch, testcase, etc.
Simon Hausmann
Comment 1 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?
Simon Hausmann
Comment 2 2012-08-24 01:58:13 PDT
CC'ing Ossy as this may possibly affect the bot operations, depending on the solution.
Csaba Osztrogonác
Comment 3 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?
Tor Arne Vestbø
Comment 4 2012-09-04 10:10:01 PDT
Taking
Simon Hausmann
Comment 5 2012-09-11 10:56:51 PDT
Committed r128174: <http://trac.webkit.org/changeset/128174>
Note You need to log in before you can comment on or make changes to this bug.