Commit Graph

55 Commits

Author SHA1 Message Date
Tor Arne Vestbø
fc4a6b0b97 Fix rpath on UIKit systems
Change-Id: I0b35c32f3730dc15d868b10489abeda909bbe926
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
2019-09-25 15:39:10 +02:00
Tor Arne Vestbø
1d1ed01711 Xcode: Ensure there's always a CFBundle[Short]Version[String] set
Leaving it empty resulted in errors from Xcode when compiling the app.

Task-number: QTBUG-25309
Task-number: QTBUG-74872
Change-Id: I61b0f47d754c5f5b181a6f918283d990458cc78d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2019-09-23 16:02:59 +00:00
Tor Arne Vestbø
fe2aaf1b90 qmake: Quote path to project file in Xcode project Makefile rule
Change-Id: I40aba757486548ef9f319d3176e89eb7129a007e
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2019-08-20 11:31:37 +02:00
Tor Arne Vestbø
6ac610c79b Allow specifying explicit SDK version on Apple platforms
This enables building against the latest SDK, while still opting out
of features that this SDK normally enables, by lowering the SDK version
set in the BUILD_VERSION/VERSION_MIN_MACOSX load command.

Change-Id: Id5f13524740bfbf5eda10a5d0c2e3fda04bf3f52
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
2019-08-08 10:27:28 +02:00
Tor Arne Vestbø
89e97e9937 Pass qmake arguments when creating Xcode project from Makefile
Change-Id: I0020273b200465f44a135848b4fd505793e85c30
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2019-08-01 15:24:25 +02:00
Tor Arne Vestbø
1b47e7154a Fix default rpath dirs on Apple platforms
The @executable_path relative framework directory is one step below
the executable, as in:

   Foo.app/Contents/Frameworks

not:

  Foo.app/Contents/MacOS/Frameworks

The former is what Xcode defaults to for new projects.

Change-Id: Id08f3f1d80f1c84d76fb71676c5df4a3a6b3da36
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2019-01-15 14:26:29 +00:00
Tor Arne Vestbø
5af60d3b37 macOS: Prevent checking for stale SDK without the required SDK name
There's no need to check the SDK at the root exclusive-build Makefile,
we can leave it to the individual build passes where the SDK variable
is available.

Fixes: QTBUG-72449
Change-Id: Ic829babf4c76e6d20812de0b94120199ebfb300c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2018-12-23 11:58:48 +00:00
Oswald Buddenhagen
bccb964b9a escape literal backslashes in qmake files
Task-number: QTBUG-70765
Change-Id: I56abbf19be88d01b2964980fb741567f28e4f0fa
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2018-12-12 17:24:39 +00:00
Tor Arne Vestbø
aa75697b63 Add makefile target to generate Xcode project
Removes need to manually build up qmake command line when there's
already a Makefile generated (from a recursive qmake_all run e.g.)

Instead, just run 'make xcodeproj'.

Change-Id: Ibe91b183230721a4bcaddfde53b623df00f7adb5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2018-11-20 19:51:25 +00:00
Liang Qi
b36c5bdc30 Merge remote-tracking branch 'origin/5.11' into 5.12.0
Conflicts:
	src/plugins/platforms/cocoa/qcocoaglcontext.mm
	src/plugins/platforms/xcb/qxcbscreen.h

Change-Id: If9b4c67288396ff7346088ce591c7a3588b51979
2018-11-05 09:59:59 +01:00
Tor Arne Vestbø
d555327a57 macOS: Explicitly define lower bound for supported SDK version
We need to support apps building against the 10.13 SDK, so that they
can opt out of dark mode and layer-backing. This does not mean we can't
require 10.14 to build Qt itself, but doing so should not require the
app to also build against the 10.14 SDK.

Change-Id: I53bd0fc8bf56c0be6614acec14d5173589e2620f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2018-10-26 08:54:22 +00:00
Tor Arne Vestbø
38afa46c47 macOS: Only detect changes to the SDK version within the same developer dir
We want to inform the user when they have upgraded their Xcode version
and hence have a new SDK version, which requires a complete rebuild.

Explicit changes to the Xcode selection (be it via xcode-select or
$DEVELOPER_DIR) do not affect the existing build directory, so we must
record the Xcode selection inside the build to avoid false triggering.

Change-Id: I7d13da1232226712a4951e8a360cf4b634c6fa2f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
2018-10-25 08:59:45 +00:00
Tor Arne Vestbø
a77e2f4cd4 macOS: Only verify the major and minor version of the platform SDK
Change-Id: I8de6c06e8be09483591efdf37c1631134d4ef826
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
2018-10-03 13:04:07 +00:00
Tor Arne Vestbø
55e63ddbd2 macOS: Bump the SDK version we've tested with to 10.14
Change-Id: Ibfdb8be91be46b22e0f0b97105121176a02a8576
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
2018-10-03 13:04:00 +00:00
Tor Arne Vestbø
4e4057460a macOS: Warn the user when using incompatible or untested platform SDKs
Task-number: QTBUG-70263
Change-Id: Ic946d1efc69ebb8ba65bbba956ed55ab7183957e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
2018-08-31 12:25:23 +00:00
Tor Arne Vestbø
3ed306772e macOS: Detect changes to the platform SDK and ask the user to deal with it
Otherwise the SDK upgrade (or downgrade) may subtly and silently affect
the resulting binary, or if it results in build breaks, the user won't
know why.

We limit it to applications for now, as that's the point where it's
most important to catch the SDK upgrade, but technically we should
also do this for intermediate libraries. Doing it for everything
will likely incur a performance cost, so we skip that for now.

Change-Id: I8a0604aad8b1e9fba99848ab8ab031c07fd50dc4
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
2018-08-31 12:25:19 +00:00
Andy Shaw
3c2ffd7457 macOS: Use QMAKE_BUNDLE for the app part of the bundle identifier value
If QMAKE_BUNDLE is set then this should be used for the bundle
identifier value instead of the product name. This ensures that when an
application provisioning profile is used that it will correctly match
against it. This also brings it in line with the documented behavior.

Change-Id: I627d212f59d862e7a881941748db5ef98ab4f463
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2018-07-18 16:58:47 +00:00
Christoph Keller
8c029e98bf Fix build of applications on iOS
When QMAKE_TARGET_BUNDLE_PREFIX is set in the .pro file then
this value should be used instead of the default value for
PRODUCT_BUNDLE_IDENTIFIER. Therefore, PRODUCT_BUNDLE_IDENTIFIER
should be set inside default_post.prf so that it can take the
value of QMAKE_TARGET_BUNDLE_PREFIX after it may have been set.

Task-number: QTBUG-66462
Change-Id: Iec1e2a43632efe6021b9d6bfdb78bd941326c456
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
2018-05-13 08:48:53 +00:00
Jake Petroules
0749ba2c5e Rewrite the Info.plist variable replacement handling
This ensures that the same set of variables can be successfully replaced
in both the Makefile and Xcode generators. It also switches the default
templates to use the Xcode-style ${var} syntax instead of the @var@
syntax for better Info.plist compatibility across generators.

Change-Id: Iff330bafd152773aafac9143c4a34e34f92f0ce6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
2018-01-06 19:46:00 +00:00
Jake Petroules
fa7626713b Allow using Xcode Command Line Tools to build Qt
Some users don't want to download the full Xcode installation which can
weigh upwards of 5 GB download and 20 GB installed.

[ChangeLog][macOS / iOS] Qt can now be built using just the Xcode
Command Line Tools, without needing to install the full Xcode IDE.

Task-number: QTBUG-35928
Task-number: QTBUG-41908
Change-Id: I6d13c9a03ab9087b3ab56e8547f53f0cc2806c7b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
2017-06-29 02:00:12 +00:00
Tor Arne Vestbø
77c2dd4017 Only use -Xarch when specifying precompiled header if building multi arch
The -Xarch option is not supported by ccache, so unless we need to
distinguish precompiled headers for multiple architectures it's better
to not pass it.

Change-Id: Iae02d37f7a89aedebecedff7290f88d2de1ca362
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
2017-06-12 16:05:33 +00:00
Jake Petroules
097073fa67 Fix precompiled headers on Apple platforms, with multiple architectures
The original commit only added support for GCC and Clang, but not ICC.

Amends 73331eeb

Change-Id: Id7638cf1b538edb1008fb3aa10754c1f517a994f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
2017-04-14 00:00:56 +00:00
Thiago Macieira
8ccd38d20d Move Apple-specific -fapplication-extensions option to the mkspec
The Intel compiler does not know about it.

Change-Id: I523b0abacd5148b2bf08fffd14b4748c3b33c8fb
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
2017-04-12 03:37:01 +00:00
Liang Qi
d51c3ecf8e Merge remote-tracking branch 'origin/5.8' into 5.9
Conflicts:
	examples/network/network.pro
	mkspecs/features/mac/default_post.prf
	src/corelib/io/qfilesystemengine_win.cpp
	src/corelib/io/qprocess.cpp
	src/corelib/io/qprocess.h
	src/corelib/io/qprocess_p.h
	src/corelib/io/qprocess_unix.cpp
	src/corelib/io/qprocess_win.cpp
	src/corelib/thread/qmutex.cpp
	src/platformsupport/fontdatabases/windows/windows.pri
	src/plugins/platforms/eglfs/eglfsdeviceintegration.pro
	tests/auto/corelib/io/io.pro

Change-Id: I8a27e0e141454818bba9c433200a4e84a88d147e
2017-03-13 15:55:44 +01:00
Jake Petroules
c0af8cef2f Don't pass -headerpad_max_install_names when using Bitcode
It is ignored (and is unnecessary to begin with) in that case,
and emits an annoying warning which this patch silences.

Change-Id: I6059969724b203d6e0e2eea81ad3e3e8f8d536d6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
2017-03-07 01:05:16 +00:00
Oswald Buddenhagen
dcd5cb9736 Merge remote-tracking branch 'gerrit/dev' into HEAD 2017-02-01 21:00:55 +01:00
Jake Petroules
ad4f7b59ea Fix iOS build
This fixes a regression introduced in the merge 318b5856.

Due to the removal of actual simulator_and_device in 5.8 (397f345a6),
conditions using it have become meaningless.

Task-number: QTBUG-58440
Change-Id: I9f874f9f85efa590c40602dbcd07793ff17d35f5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
2017-01-30 17:31:28 +00:00
Jake Petroules
944110089d Build Qt libraries with -fapplication-extension
This ensures at compile-time that Qt libraries do not use any APIs that
are not safe for use in application extensions, and fixes warning
messages that appear when linking to Qt libraries that are not built
with this flag, when used in an application extension.

This is especially important on watchOS where *all* "applications" are
actually application extensions, and on other Apple platforms if
application extensions are developed using Qt.

Task-number: QTBUG-40101
Change-Id: I022046f2584e0222253d33052b0abc221d7c93d6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2017-01-27 22:10:01 +00:00
Liang Qi
318b58562a Merge remote-tracking branch 'origin/5.8' into dev
Conflicts:
	.qmake.conf
	mkspecs/common/msvc-desktop.conf
	mkspecs/common/msvc-version.conf
	mkspecs/common/winrt_winphone/qmake.conf
	mkspecs/features/mac/default_post.prf
	mkspecs/features/mac/sdk.prf
	mkspecs/features/qt.prf
	mkspecs/features/uikit/default_post.prf
	mkspecs/features/winrt/default_pre.prf
	mkspecs/winphone-arm-msvc2013/qmake.conf
	mkspecs/winphone-x86-msvc2013/qmake.conf
	mkspecs/winrt-arm-msvc2013/qmake.conf
	mkspecs/winrt-x64-msvc2013/qmake.conf
	mkspecs/winrt-x86-msvc2013/qmake.conf
	qmake/generators/win32/msvc_vcproj.cpp
	src/gui/kernel/qwindowsysteminterface.cpp
	src/network/kernel/qhostaddress.cpp
	src/plugins/platforms/mirclient/qmirclientplugin.cpp
	src/plugins/platforms/mirclient/qmirclientplugin.h
	src/widgets/util/qsystemtrayicon.cpp
	tests/auto/widgets/itemviews/qlistview/tst_qlistview.cpp
	tools/configure/Makefile.mingw
	tools/configure/Makefile.win32

Done-with: Jake Petroules <jake.petroules@qt.io>
Done-with: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Change-Id: I4be3262d3994e11929d3b1ded2c3379783797dbe
2017-01-25 20:06:06 +01:00
Oswald Buddenhagen
70a7276840 de-duplicate {mac,uikit}/default_post.prf re valid architectures
Change-Id: Ie9d5a35a7f8578a2588ec004aab086d74986b0eb
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
2016-12-30 10:25:32 +00:00
Oswald Buddenhagen
b5c809eb96 remove redundant arch list truncation in single_arch case
beyond this point, simulator_archs is only used to determine from which
one of the lists the remaining arch came from (and device_archs is
actually never used again). the lists are assumed to be mutually
exclusive, so truncating them won't affect in which of them the first
element of their concatenation is found.

Change-Id: I4736ed7e51f6623efa6bd37892ab1fcf8c83ae8b
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
2016-12-30 10:25:28 +00:00
Oswald Buddenhagen
afd82630c2 delay resolution of darwin deployment target and architectures
there appears to be no particular reason why this ended up in sdk.prf,
and it has become an actual problem now that the sdk is resolved from
default_pre.prf already, making it impossible for projects to override
the deployment target.

Task-number: QTBUG-56965
Change-Id: I8e319d10cdfb95acc1da1f431c8b8d4f76d1168e
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
2016-12-30 10:25:22 +00:00
Liang Qi
e5ac4afbf9 Merge remote-tracking branch 'origin/5.8' into dev
Conflicts:
	mkspecs/features/mac/default_post.prf
	mkspecs/features/uikit/default_post.prf

Change-Id: I2a6f783451f2ac9eb4c1a050f605435d2dacf218
2016-11-17 14:43:26 +01:00
Liang Qi
d7e4980132 Merge remote-tracking branch 'origin/5.8' into dev
Blacklist tst_QMenuBar::taskQTBUG46812_doNotLeaveMenubarHighlighted() on macOS.

Conflicts:
	mkspecs/features/mac/default_post.prf
	mkspecs/features/mac/sdk.prf
	mkspecs/features/uikit/default_post.prf
	mkspecs/features/uikit/sdk.prf
	src/angle/src/libEGL/libEGL.pro
	src/platformsupport/fontdatabases/fontdatabases.pro
	src/platformsupport/platformsupport.pro
	src/plugins/platforms/cocoa/qnswindowdelegate.mm
	src/plugins/platforms/direct2d/qwindowsdirect2dintegration.cpp
	src/plugins/platforms/ios/ios.pro
	src/plugins/platforms/ios/kernel.pro
	tests/auto/widgets/widgets/qmenubar/BLACKLIST
	tests/auto/widgets/widgets/qmenubar/tst_qmenubar.cpp

Task-number: QTBUG-56853
Change-Id: If58785210feee3550892fc7768cce90e75a2416c
2016-11-02 09:24:11 +01:00
Oswald Buddenhagen
418494ecb6 fix QMAKE_DEFAULT_*DIRS resolution with apple SDK, take 2
the code got factored out to an own toolchain.prf file, which is
load()ed from default_pre.prf, so no change at first.
however, on mac, we shadow toolchain.prf, and make it load() sdk.prf
first.

a side effect, it has become harder to disable the use of an sdk
altogether: putting CONFIG-=sdk into a project file or the qmake
command line has no effect now. instead, it's possible to put it into
.qmake.{conf,cache}.
to make it simpler again, it's conceivable to finally add qmake -pre,
which would allow setting variables before default_pre.prf is executed.

take 2: there was nothing wrong with the original patch, but in 5.8,
CONFIG+=simulator_and_device moved from qconfig.pri to various prf files
that would do it according to the simulator_and_device configure
feature, which would be way too late for the "pulled ahead" sdk.prf
loading. as simulator_and_device is now gone entirely, it is safe to
re-apply this patch (mostly) as-is.

Task-number: QTBUG-56144
Change-Id: I6cf484982eaed8af39f7a539c60f5a087a299914
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
2016-10-16 00:12:11 +00:00
Jake Petroules
28f5d79316 Share the multi-arch infrastructure between UIKit and macOS
There's no reason for this to be separated, regardless of the
support status of i386 macOS builds. Additional architectures may
appear in the future (and currently there's actually 3 - i386,
x86_64, and x86_64h for Haswell CPUs). So this feature could be
used to get combined generic x86_64 and Haswell builds. Some
system libraries appear to have an x86_64h slice in Sierra.

[ChangeLog][Build System] Support for universal binaries on macOS
has been re-introduced.

Change-Id: I1c89904addf024431fdb3ad03ea8ab85da7240ad
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
2016-09-29 21:51:18 +00:00
Jake Petroules
261f6ad074 Fix warning about headerpad_max_install_names ignored when using bitcode
Actually enables headerpad_max_install_names in the darwin-g++ mkspec
as previously it was (presumably accidentally) cleared.

Change-Id: I4b2e5a0dcf38658cfe35bc0e5f24769c80f4d877
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2016-08-31 22:42:04 +00:00
Jake Petroules
f777b1ae48 Provide better QMAKE_RPATHDIR defaults on Apple platforms
Now QMAKE_RPATHDIR also includes @executable_path and @loader_path
on Apple platforms, and omits any others on iOS, tvOS, and watchOS
since they can't use paths outside the application bundle.

Change-Id: Ia8f76ebcddd51f44eca482a51ce1710369c8df10
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2016-08-31 22:41:58 +00:00
Lars Knoll
60985aa42b Use qtConfig throughout in qtbase
Use the new qtConfig macro in all pro/pri files.

This required adding some feature entries, and adding
{private,public}Feature to every referenced already existing entry.

Change-Id: I164214dad1154df6ad84e86d99ed14994ef97cf4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2016-08-19 04:28:05 +00:00
Oswald Buddenhagen
967372c975 sanitize qt rpath handling, in particular on mac
the addition of qt's rpath belongs into qt.prf - even on mac.
so consolidate the two implementations.
as a nice "side effect", we get relative rpaths also on linux.
another "side effect" is that we don't unnecessarily add the qt rpath to
qt modules also on linux.

the qt rpath addition mechanism should not be responsible for setting
the policy who gets a relative rpath, so move the logic to higher-level
callers.

Change-Id: I52e8fe2e8279e7b1ac25fae758867a5cb1cafcf8
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2015-09-17 16:36:12 +00:00
Oswald Buddenhagen
f58e95f098 remove some mac multiarch vestiges
ppc/ppc64 and 32-bit x86 have been dead for a while.

consequently, the legacy macx-g++-64 spec was most probably not used.

which in turn meant that NATIVE_64_ARCH was never set (in particular on
windows hosts ...), which means that the android ndk host auto-detection
was effectively broken.

the arch code in mac/default_post.prf was also never triggered, so nuke
it as well.

Change-Id: Ic0775e40b273a22e0a15808cac328e0df33c2155
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2015-09-17 16:35:46 +00:00
Tor Arne Vestbø
ef4ef2884d Use absolute rpath to Qt libraries for non-prefix builds
Task-number: QTBUG-46391
Change-Id: Iaebba29c340fb027e23a0923f3692d47f9d450d5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
2015-06-04 10:22:58 +00:00
Adam Strzelecki
e0676a954c Add rpath pointing to Qt libraries in OS X and iOS
This is triggered only when app is using Qt and Qt was built with "rpath"
configuration and project does not specify QMAKE_RPATHDIR explicitly.

Added rpath is made relative to app binary location if target path lies inside
Qt SDK, so all SDK bundled tools and examples will work automatically without
any changes. Tests are an exception here, since they are being run from their
build location by CI, we may not use relative rpath that work only in install
location.

Task-number: QTBUG-31814
Change-Id: I3690f29d2b5396a19c1dbc92ad05e6c028f8515b
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
2014-11-01 19:26:12 +01:00
Tor Arne Vestbø
02ecd3ae40 Make Xcode debug info format controllable through a qmake variable
The default is still DWARF instead of DWARF with dSYM for static builds
of Qt, so that debug builds of the final application don't take forever
to build due to generating the dSYM file.

Change-Id: I370d800d7c959e05c1a8780c4ebf58fff250daa1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
2014-04-10 00:44:44 +02:00
Tor Arne Vestbø
4c980d2e9b Explicitly use libstdc++ for non-C++11 static builds
Otherwise the compiler may choose libc++ based on the deployment target,
and we'll end up with broken builds due to the mismatch between the two
libraries, eg:

Undefined symbols for architecture x86_64:
  "std::ios_base::Init::Init()", referenced from:
      __GLOBAL__I_a in libQt5Qml.a(qv4object.o)
      ...
  "std::ios_base::Init::~Init()", referenced from:
      __GLOBAL__I_a in libQt5Qml.a(qv4object.o)
      ...
  "std::__throw_length_error(char const*)", referenced from:
      ...

This problem is not iOS specific, which is why the logic is moved
to the more generic mac/default_post.prf.

Change-Id: I28b94e614f9167fc0db84bbf1c88dd97d5629938
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2014-01-28 02:33:40 +01:00
Tor Arne Vestbø
a4e0f4f80a Ensure C++11 support matches between Qt and user projects for static builds
Change-Id: Id529fb7fc52d2da312bcf17612e47c74939a617f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
2014-01-28 02:33:32 +01:00
Oswald Buddenhagen
53280989fb use the new "stash" instead of the (anything but) "regular" cache
as this new cache category comes without side effects, we can
unconditionally create a cache whereever we are. this allows us to be
performant without explicit user action.

Task-number: QTBUG-31340
Change-Id: I6b88b20b61e8351aa8cbf94ad3eec65adac6e1d6
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2013-11-14 19:26:20 +01:00
Tor Arne Vestbø
25650923b1 xcode: Set QMAKE_XCODE_LIBRARY_SUFFIX from default_post
Otherwise we won't pick up CONFIG+= changes on the command line or
from the project file.

Change-Id: I6f7e9380f971e6271de5659534e9565024fe041d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-10-25 20:50:51 +02:00
Morten Johan Sørvig
8fc97fdfc7 Revert Mac event loop changes.
"Make QGuiApplication::exec() run within NSApplicationMain()"
"Make Qt process native and timer events on Cocoa applications"
"Cocoa: Fix QFontDialog, QColorDialog auto-tests"

This reverts commits
1e14762b8d
e4b2a0b4ba
df7944e7d7

Change-Id: I80b65b5ee0297b090f807bd420664233dfc44f7b
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com>
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
2013-09-02 13:07:35 +02:00
Gabriel de Dietrich
1e14762b8d Make QGuiApplication::exec() run within NSApplicationMain()
We follow the same pattern as for iOS and Windows ports, making
sure the user's main() runs in a platform friendly environment. In
this particular case, it means calling the user's main() during the
call of NSApplicationMain(), and calling the user's main() function
(renamed to qMain() as in Windows) after receiving
NSApplicationDidFinishLaunchingNotification. In practice, this means
that NSApp is running when qMain() is called, and therefore when
QCoreApplication::exec() is called.

For those command-line utilities running on QGuiApplication, or any
deriving class, and that do not provide a bundle, we override the main
bundle's dictionary and get NSApplicationMain() to run as usual.

Added cocoa/cocoamain "subdir" to build libqtcocoamain.a (together with
cocoa/cocoaplugin -- plugins/platforms/cocoa is made a subdirs project).
This library is linked against all GUI Qt apps and provides the actual
main() function. It also catches the launching NSApplication notifications,
and calls the user's qMain() function. Note that this will happen in the
same cases when the user's application will run with the Cocoa QPA plugin.

Launch related code in QCocoaApplicationDelegate is moved to libqtcocoamain,
QNSApplication is removed (but sendEvent: redirection still there), and
code in QCocoaEventDispatcher dealing with calling [NSApp run] and related
has been removed since it's become unreachable.

ChangeLog: [Qt for Mac] Make QGuiApplication::exec() run within NSApplicationMain()
Change-Id: I790e5138c29aac2e0215a9147d0148fece40ca22
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
2013-08-29 12:44:07 +02:00