Bug 15614 - [GTK] qmake based backends don't build on OS X
Summary: [GTK] qmake based backends don't build on OS X
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
Keywords: Gtk
Depends on:
Reported: 2007-10-22 04:57 PDT by Sven Herzberg
Modified: 2008-02-04 02:50 PST (History)
1 user (show)

See Also:

Proposed patch (914 bytes, patch)
2007-10-22 05:31 PDT, Sven Herzberg
no flags Details | Formatted Diff | Diff
stderr (without patch) (2.95 KB, application/octet-stream)
2007-10-22 06:49 PDT, Sven Herzberg
no flags Details
stderr (with patch v2) (4.60 KB, application/octet-stream)
2007-10-22 07:00 PDT, Sven Herzberg
no flags Details
Proposed patch (v2) (7.64 KB, patch)
2007-10-22 07:01 PDT, Sven Herzberg
no flags Details | Formatted Diff | Diff
Proposed patch (v3) (1.07 KB, patch)
2007-10-22 07:09 PDT, Sven Herzberg
no flags Details | Formatted Diff | Diff
Proposed patch (v4) (2.34 KB, patch)
2007-10-24 03:46 PDT, Sven Herzberg
no flags Details | Formatted Diff | Diff
Proposed patch (v4) (1.80 KB, patch)
2007-10-24 03:48 PDT, Sven Herzberg
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Herzberg 2007-10-22 04:57:42 PDT
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
Calling 'qmake -r
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
Reading /Users/herzi/Source/webkit-qt/JavaScriptCore/pcre/dftables.pro
Reading /Users/herzi/Source/webkit-qt/WebCore/WebCore.pro
Reading /Users/herzi/Source/webkit-qt/JavaScriptCore/kjs/testkjs.pro
WARNING: Ignored (not found)
WARNING: Ignored (not found)
WARNING: Ignored (not found)
WARNING: Ignored (not found)
WARNING: Ignored (not found)
WARNING: Ignored (not found)
make: *** No targets specified and no makefile found.  Stop.
Comment 1 Sven Herzberg 2007-10-22 05:31:10 PDT
Created attachment 16791 [details]
Proposed patch
Comment 2 Mark Rowe (bdash) 2007-10-22 06:21:02 PDT
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.
Comment 3 Sven Herzberg 2007-10-22 06:26:45 PDT
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
Comment 4 Holger Freyther 2007-10-22 06:37:46 PDT
(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+....
Comment 5 Mark Rowe (bdash) 2007-10-22 06:40:27 PDT
It was.
Comment 6 Sven Herzberg 2007-10-22 06:49:44 PDT
Created attachment 16794 [details]
stderr (without patch)

This is the output without the patch
Comment 7 Sven Herzberg 2007-10-22 07:00:48 PDT
Created attachment 16795 [details]
stderr (with patch v2)
Comment 8 Sven Herzberg 2007-10-22 07:01:27 PDT
Created attachment 16796 [details]
Proposed patch (v2)

Including proposed changes
Comment 9 Sven Herzberg 2007-10-22 07:09:06 PDT
Created attachment 16797 [details]
Proposed patch (v3)

Updated the branch to reduce the diff size
Comment 10 Sven Herzberg 2007-10-22 07:33:58 PDT
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()


* adding isDarwin() (and using it within the osOSX() test as well) would be less intrusive
Comment 11 Sven Herzberg 2007-10-24 03:46:07 PDT
Created attachment 16832 [details]
Proposed patch (v4)

Updated to latest HEAD and included the isDarwin() changes
Comment 12 Sven Herzberg 2007-10-24 03:48:53 PDT
Created attachment 16833 [details]
Proposed patch (v4)

Still the same, but with color-escapes...
Comment 13 Mark Rowe (bdash) 2007-10-24 22:12:28 PDT
Landed in r27015.
Comment 14 Mark Rowe (bdash) 2007-10-24 23:03:01 PDT
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.
Comment 15 Mark Rowe (bdash) 2007-10-24 23:30:20 PDT
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.
Comment 16 Darin Adler 2007-10-28 14:36:26 PDT
Comment on attachment 16833 [details]
Proposed patch (v4)

Clearing the review flag since this patch was landed.
Comment 17 Alp Toker 2008-02-04 02:50:20 PST
This issue is fixed. (Sounds like it's not considered a bug for Qt.)

Closing it.