Bug 94914
| Summary: | [Qt] WebKit fails to detect QtQuick2 if Qt is built with -prefix | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Hausmann <hausmann> |
| Component: | Platform | Assignee: | Tor Arne Vestbø <vestbo> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | ossy, rafael.lobo, vestbo |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 76773 | ||
Simon Hausmann
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
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
CC'ing Ossy as this may possibly affect the bot operations, depending on the solution.
Csaba Osztrogonác
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ø
Taking
Simon Hausmann
Committed r128174: <http://trac.webkit.org/changeset/128174>