Fixed compile on mac (workaround for build system bug)

When using QT += somemodule, and using frameworks on mac, qmake refuses
to add `-framework somemodule' to the compiler flags unless the
framework can be found on disk.  This can easily break when compiling
two frameworks out of the same source tree.

In this case, if QtQuick1 were qmake'd prior to QtDeclarative being
built (which is expected for a clean build), it would incorrectly put
-lQtDeclarative into the link line even if QtDeclarative should be
built as a framework.  The problem would disappear if qmake was re-run.

Change-Id: I79cbfc454e0ab564ce6597b4f7e613c1ff39473f
Reviewed-on: http://codereview.qt-project.org/4938
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Michael Brasser <michael.brasser@nokia.com>

diff --git a/src/qtquick1/qtquick1.pro b/src/qtquick1/qtquick1.pro
index d70b532..65010fe 100644 (file)
--- a/src/qtquick1/qtquick1.pro
+++ b/src/qtquick1/qtquick1.pro
@@ -40,3 +40,16 @@ SOURCES += qtquick1.cpp
 DEFINES += QT_NO_OPENTYPE
 INCLUDEPATH +=  $$QT.corelib.sources/../src/3rdparty/harfbuzz/src
 
+mac {
+    # FIXME: this is a workaround for broken qmake logic in qtAddModule()
+    # This function refuses to use frameworks unless the framework exists on
+    # the filesystem at the time qmake is run, resulting in a build failure
+    # if QtQuick1 is qmaked before QtDeclarative is built and frameworks are
+    # in use. qtAddLibrary() contains correct logic to deal with this, so
+    # we'll explicitly call that for now.
+    load(qt)
+    LIBS -= -lQtDeclarative        # in non-framework builds, these should be re-added
+    LIBS -= -lQtDeclarative_debug  # within the qtAddLibrary if appropriate, so no
+    qtAddLibrary(QtDeclarative)    # harm done :)
+}
+