Bug 95736 - hybridPixmap test fails to compile
Summary: hybridPixmap test fails to compile
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Qt (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P2 Normal
Assignee: Nobody
Depends on:
Blocks: 76773
  Show dependency treegraph
Reported: 2012-09-04 05:05 PDT by Jonathan Liu
Modified: 2012-09-06 04:58 PDT (History)
4 users (show)

See Also:

Patch (1.05 KB, patch)
2012-09-04 05:07 PDT, Jonathan Liu
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Liu 2012-09-04 05:05:09 PDT
I get a compile error compiling the hybridPixmap test while building WebKit for Qt 5.
It complains while compiling ui_widget.h that it is unable to find widget.h.
The directory containing widget.h is not in any of the include paths.
Comment 1 Jonathan Liu 2012-09-04 05:07:59 PDT
Created attachment 162016 [details]
Comment 2 Simon Hausmann 2012-09-05 22:35:59 PDT
This is happening for you only on Windows, right?

I'm a bit puzzled since I don't see the problem with nmake and msvc (different qmake backend) or with gcc on other platforms (pretty much same backend as mingw)
Comment 3 Jonathan Liu 2012-09-05 22:40:24 PDT
I am compiling Qt 5 and QtWebkit with MinGW on Windows as described on http://qt-project.org/wiki/Building_Qt_5_from_Git with the Tools/Scripts/build-webkit script. There is a -I include for the parent directory of hybridPixmap but there is no include for the hybridPixmap directory itself.
Comment 4 Simon Hausmann 2012-09-06 04:15:22 PDT
I think I've found the reason as to why you're seeing this and I don't. Here's a simplified test-case to illustrate the issue. Imagine the following directory / file structure:


Suppose someheader.h contains #include "anotherheader.h" and main.cpp includes "someheader.h".

When someheader.h is pre-processed the pre-processor will look for anotherheader.h first inside somedirectory. After that GNU CPP stops, whereas MSVC continues "in the directories of any previously opened include files in the reverse order in which they were opened" (from http://msdn.microsoft.com/en-us/library/36k2cdd4.aspx ). qmake seems to have a mechanism for g++ on Linux to make sure that at least the initial "source" directory is in the include search paths, covering this particular issue, but that doesn't seem to be in place for windows builds. Maybe because MSVC doesn't need it, but then it's leaving out g++ on Windows. I'll dig a bit further into qmake for this.
Comment 5 Simon Hausmann 2012-09-06 04:58:05 PDT
I believe that this is a qmake issue. I've made a patch that can be tracked at


I'm closing this as INVALID, as I believe the bug is in qmake. Let's hope we can fix it there :)
Comment 6 Simon Hausmann 2012-09-06 04:58:23 PDT
Comment on attachment 162016 [details]

Clearing review on the patch, I don't believe that patch should be needed.