Bug 95736 – hybridPixmap test fails to compile

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit Qt

[Jonathan Liu]

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.

[Jonathan Liu]

Created attachment 162016 [details]
Patch

[Simon Hausmann]

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)

[Jonathan Liu]

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.

[Simon Hausmann]

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:

   main.cpp
   somedirectory\someheader.h
   anotherheader.h

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.

[Simon Hausmann]

I believe that this is a qmake issue. I've made a patch that can be tracked at

    https://codereview.qt-project.org/#change,34323

I'm closing this as INVALID, as I believe the bug is in qmake. Let's hope we can fix it there :)

[Simon Hausmann]

Comment on attachment 162016 [details]
Patch

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