summaryrefslogtreecommitdiffstats
path: root/mkspecs/features/mac/default_post.prf
Commit message (Collapse)AuthorAgeFilesLines
* Fix precompiled headers on Apple platforms, with multiple architecturesJake Petroules2017-04-141-4/+14
| | | | | | | | | | 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>
* Move Apple-specific -fapplication-extensions option to the mkspecThiago Macieira2017-04-121-4/+4
| | | | | | | The Intel compiler does not know about it. Change-Id: I523b0abacd5148b2bf08fffd14b4748c3b33c8fb Reviewed-by: Jake Petroules <jake.petroules@qt.io>
* Merge remote-tracking branch 'origin/5.8' into 5.9Liang Qi2017-03-131-0/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * Don't pass -headerpad_max_install_names when using BitcodeJake Petroules2017-03-071-0/+7
| | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'gerrit/dev' into HEADOswald Buddenhagen2017-02-011-7/+75
|\ \
| * | Fix iOS buildJake Petroules2017-01-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | Merge remote-tracking branch 'origin/5.8' into devLiang Qi2017-01-251-7/+75
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| | * de-duplicate {mac,uikit}/default_post.prf re valid architecturesOswald Buddenhagen2016-12-301-8/+9
| | | | | | | | | | | | | | | Change-Id: Ie9d5a35a7f8578a2588ec004aab086d74986b0eb Reviewed-by: Jake Petroules <jake.petroules@qt.io>
| | * remove redundant arch list truncation in single_arch caseOswald Buddenhagen2016-12-301-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | * delay resolution of darwin deployment target and architecturesOswald Buddenhagen2016-12-301-5/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Build Qt libraries with -fapplication-extensionJake Petroules2017-01-271-0/+7
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.8' into devLiang Qi2016-11-171-0/+3
|\| | | | | | | | | | | | | | | Conflicts: mkspecs/features/mac/default_post.prf mkspecs/features/uikit/default_post.prf Change-Id: I2a6f783451f2ac9eb4c1a050f605435d2dacf218
* | Merge remote-tracking branch 'origin/5.8' into devLiang Qi2016-11-021-1/+1
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * fix QMAKE_DEFAULT_*DIRS resolution with apple SDK, take 2Oswald Buddenhagen2016-10-161-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Share the multi-arch infrastructure between UIKit and macOSJake Petroules2016-09-291-9/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Fix warning about headerpad_max_install_names ignored when using bitcodeJake Petroules2016-08-311-0/+2
| | | | | | | | | | | | | | | | 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>
* | Provide better QMAKE_RPATHDIR defaults on Apple platformsJake Petroules2016-08-311-0/+7
|/ | | | | | | | | 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>
* Use qtConfig throughout in qtbaseLars Knoll2016-08-191-2/+2
| | | | | | | | | | | 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>
* sanitize qt rpath handling, in particular on macOswald Buddenhagen2015-09-171-25/+0
| | | | | | | | | | | | | | | | 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>
* remove some mac multiarch vestigesOswald Buddenhagen2015-09-171-14/+1
| | | | | | | | | | | | | | | | | 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>
* Use absolute rpath to Qt libraries for non-prefix buildsTor Arne Vestbø2015-06-041-9/+10
| | | | | | Task-number: QTBUG-46391 Change-Id: Iaebba29c340fb027e23a0923f3692d47f9d450d5 Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
* Add rpath pointing to Qt libraries in OS X and iOSAdam Strzelecki2014-11-011-0/+24
| | | | | | | | | | | | | | | 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>
* Make Xcode debug info format controllable through a qmake variableTor Arne Vestbø2014-04-101-0/+7
| | | | | | | | | | 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>
* Explicitly use libstdc++ for non-C++11 static buildsTor Arne Vestbø2014-01-281-0/+9
| | | | | | | | | | | | | | | | | | | | | | 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>
* Ensure C++11 support matches between Qt and user projects for static buildsTor Arne Vestbø2014-01-281-2/+11
| | | | | | Change-Id: Id529fb7fc52d2da312bcf17612e47c74939a617f Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* use the new "stash" instead of the (anything but) "regular" cacheOswald Buddenhagen2013-11-141-7/+2
| | | | | | | | | | 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>
* xcode: Set QMAKE_XCODE_LIBRARY_SUFFIX from default_postTor Arne Vestbø2013-10-251-0/+2
| | | | | | | | | 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>
* Revert Mac event loop changes.Morten Johan Sørvig2013-09-021-14/+0
| | | | | | | | | | | | | | | "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 1e14762b8d79118540bd09a84dd3e48f4f5e113e e4b2a0b4bab2a17a65fedafe9bae50af1fe019f6 df7944e7d7dd8b2bbccbd639eff0ab09745d6cc3 Change-Id: I80b65b5ee0297b090f807bd420664233dfc44f7b Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com> Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Make QGuiApplication::exec() run within NSApplicationMain()Gabriel de Dietrich2013-08-291-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Mac: Ensure that C++11 is always used when linking against a static Qt buildTor Arne Vestbø2013-06-241-5/+8
| | | | | | | | | | | | | 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>
* Cache Xcode and SDK settings in .qmake.cache if it existsTor Arne Vestbø2013-05-081-0/+8
| | | | | | | | | | | | | | | 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>
* Load sdk.prf first, if enabled, so that other features can use QMAKE_CXXTor Arne Vestbø2013-04-031-0/+4
| | | | | | | | 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>
* Fix whitespace issues in *.prfAxel Waggershauser2013-03-221-1/+1
| | | | | | | | 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>
* Initial import from the monolithic Qt.Qt by Nokia2011-04-271-0/+17
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
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-30 22:52:14 +0000