Commit Graph

16 Commits

Author SHA1 Message Date
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
Tor Arne Vestbø
d0d158f092 Mac: Ensure that C++11 is always used when linking against a static Qt build
If Qt was built with C++11, it links to libc++, and we need all projects
that use Qt to link against the same library.

Technically, we could do QMAKE_LFLAGS += -stdlib=libc++, but that hasn't
been tested enough without also enabling C++11, so we keep the
relationship between the two for now.

Change-Id: Ic628bcbade60cc82f93707f372c2119c24d9dc8a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Liang Qi <liang.qi@digia.com>
2013-06-24 14:51:50 +02:00
Tor Arne Vestbø
1308aa25fb Cache Xcode and SDK settings in .qmake.cache if it exists
The Xcode and SDK settings are expensive to resolve, as we're using
system() calls to resolve them. We now try to detect the presence of
a .qmake.cache file (and inform the user that creating one would be
a good idea), and use the file to cache the various settings after
resolving them.

The Xcode logic had to be moved form xcode.conf as part of the mkspec,
into default_pre/post.prf, so that we could cache() the resolved values.

Task-number: QTBUG-30586
Change-Id: Ib5368cfee6f7e4a4a33f6be70d0e20d96896fe56
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-05-08 14:07:41 +02:00
Tor Arne Vestbø
b2d7168313 Load sdk.prf first, if enabled, so that other features can use QMAKE_CXX
Extra-compilers such as objective_c.prf may reference QMAKE_CXX, so we
need to sysroot it before it's used.

Change-Id: I1e367b3d0816096300a441786619f298134de0a6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-04-03 17:16:43 +02:00
Axel Waggershauser
1622dca213 Fix whitespace issues in *.prf
Replaced tabs with spaces to align with space-indented code
and removed some trailing whitespace.

Change-Id: I4930afc3df206ef8ee96de3e69f0d69fc4a1c77c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
2013-03-22 19:52:26 +01:00
Qt by Nokia
38be0d1383 Initial import from the monolithic Qt.
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
Qt Git wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:

http://qt.gitorious.org/qt/pages/GitIntroductionWithQt

If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.

Branched from the monolithic repo, Qt master branch, at commit
896db169ea224deb96c59ce8af800d019de63f12
2011-04-27 12:05:43 +02:00