Bug 15614 – [GTK] qmake based backends don't build on OS X

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Sven Herzberg]

The QT and GTK backends require qmake to output makefiles instead of xcode projects. I reported this as a bug at Trolltech, but they told me to set the spec for qmake correctly. I'm going to attach a patch for this (the binary that Trolltech delivers has got this issue, qmake built from source works out of the box).

This was the output for the QT build, but with the patch from bug 15229 GTK+ should work as well (in fact, I'm updating the patch for that other bug now on MacOS X.

Here's the output from the build I attempted with the qt backend (but applies to the GTK backend as well). Patch follows.

$ ./build-webkit --qt
Updating
/Users/herzi/Source/webkit-qt/WebKitBuild/Release/libWebKitSystemInterface.a
Updating
/Users/herzi/Source/webkit-qt/WebKitBuild/Release/usr/local/include/WebKitSystemInterface.h
Calling 'qmake -r
OUTPUT_DIR=/Users/herzi/Source/webkit-qt/WebKitBuild/Release
CONFIG+=qt-port /Users/herzi/Source/webkit-qt/WebKit.pro
CONFIG+=release CONFIG-=debug' in
/Users/herzi/Source/webkit-qt/WebKitBuild/Release ...

Reading /Users/herzi/Source/webkit-qt/WebKitQt/Plugins/Plugins.pro
[/Users/herzi/Source/webkit-qt/WebKitBuild/Release//WebKitQt/Plugins]
Reading /Users/herzi/Source/webkit-qt/JavaScriptCore/pcre/dftables.pro
[/Users/herzi/Source/webkit-qt/WebKitBuild/Release//JavaScriptCore/pcre]
Reading /Users/herzi/Source/webkit-qt/WebCore/WebCore.pro
[/Users/herzi/Source/webkit-qt/WebKitBuild/Release//WebCore]
Reading /Users/herzi/Source/webkit-qt/JavaScriptCore/kjs/testkjs.pro
[/Users/herzi/Source/webkit-qt/WebKitBuild/Release//JavaScriptCore/kjs]
Reading
/Users/herzi/Source/webkit-qt/WebKitQt/QtLauncher/QtLauncher.pro
[/Users/herzi/Source/webkit-qt/WebKitBuild/Release//WebKitQt/QtLauncher]
Reading
/Users/herzi/Source/webkit-qt/WebKitTools/DumpRenderTree/DumpRenderTree.qtproj/DumpRenderTree.pro
[/Users/herzi/Source/webkit-qt/WebKitBuild/Release//WebKitTools/DumpRenderTree/DumpRenderTree.qtproj]
WARNING: Ignored (not found)
'/Users/herzi/Source/webkit-qt/WebKitQt/Plugins/qtwebico.xcodeproj'
WARNING: Ignored (not found)
'/Users/herzi/Source/webkit-qt/JavaScriptCore/pcre/dftables.xcodeproj'
WARNING: Ignored (not found)
'/Users/herzi/Source/webkit-qt/WebCore/QtWebKit.xcodeproj'
WARNING: Ignored (not found)
'/Users/herzi/Source/webkit-qt/JavaScriptCore/kjs/testkjs.xcodeproj'
WARNING: Ignored (not found)
'/Users/herzi/Source/webkit-qt/WebKitQt/QtLauncher/QtLauncher.xcodeproj'
WARNING: Ignored (not found)
'/Users/herzi/Source/webkit-qt/WebKitTools/DumpRenderTree/DumpRenderTree.qtproj/DumpRenderTree.xcodeproj'
make: *** No targets specified and no makefile found.  Stop.

[Sven Herzberg]

Created attachment 16791 [details]
Proposed patch

[Mark Rowe (bdash)]

The Qt port at least has worked fine for me with qmake on Mac OS X.  It is not entirely clear what the problem you're describing is.

[Sven Herzberg]

The problem is that it doesn't work out of the box with the precompiled qmake from trolltech's dmg: http://trolltech.com/developer/downloads/qt/mac

[Holger Freyther]

(In reply to comment #1)
> Created an attachment (id=16791) [edit]
> Proposed patch
> 

Looks fine. I would appreciate if QMAKESPEC would not be overwritten if it is already set. E.g. I could cross compile on my mac for any other system.

Also I wonder if isOSX() wasn't changed to return false when building for Qt/Gtk+....

[Mark Rowe (bdash)]

It was.

[Sven Herzberg]

Created attachment 16794 [details]
stderr (without patch)

This is the output without the patch

[Sven Herzberg]

Created attachment 16795 [details]
stderr (with patch v2)

[Sven Herzberg]

Created attachment 16796 [details]
Proposed patch (v2)

Including proposed changes

[Sven Herzberg]

Created attachment 16797 [details]
Proposed patch (v3)

Updated the branch to reduce the diff size

[Sven Herzberg]

I'm still not completely happy with this patch.

* if isOSX() would be only the platform-detection and not yet the backend, it would be more consistent, I guess
* isQuartz() could be a replacement for the current appearances of isOSX()

or

* adding isDarwin() (and using it within the osOSX() test as well) would be less intrusive

[Sven Herzberg]

Created attachment 16832 [details]
Proposed patch (v4)

Updated to latest HEAD and included the isDarwin() changes

[Sven Herzberg]

Created attachment 16833 [details]
Proposed patch (v4)

Still the same, but with color-escapes...

[Mark Rowe (bdash)]

Landed in r27015.

[Mark Rowe (bdash)]

George Staikos wasn't happy with this change so he removed the "isQt()" portion of the check.  From discussions on IRC I'm still not really clear *why* he was so unhappy with it, but it seems that if we were to add an additional check to verify that the qmake spec that will be used is the troublesome mac-xcode one before setting it then he would be ok with it.  That would make the condition roughly:

if ((isGtk() || isQt()) && isDarwin() && !$ENV{QMAKESPEC} && qmakeSpecIsMacXcode())

I had a quick look and wasn't sure how to determine what the default QMAKESPEC value is, other than the awkward approach of :

readlink $(qmake -query QMAKE_MKSPECS)/default


I'm reopening this bug even though this is fixed from the Gtk point of view as the original report talked about Qt primarily.

[Mark Rowe (bdash)]

George says there is currently no way to query the default QMAKESPEC.  He has filed a feature request so it will hopefully be available in a future version of qmake, but in the meantime the readlink-based approach will work for our specific Mac OS X only scenario.

[Darin Adler]

Comment on attachment 16833 [details]
Proposed patch (v4)

Clearing the review flag since this patch was landed.

[Alp Toker]

This issue is fixed. (Sounds like it's not considered a bug for Qt.)

Closing it.