summaryrefslogtreecommitdiffstats
path: root/mkspecs/features/mac
Commit message (Collapse)AuthorAgeFilesLines
* Make Xcode debug info format controllable through a qmake variableTor Arne Vestbø2014-04-102-0/+17
| | | | | | | | | | 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>
* Use PlistBuddy instead of sed/xpath magic to extract OS X/iOS SDK nameTor Arne Vestbø2014-04-081-6/+1
| | | | | | | | Change-Id: I9e9f9b033cc892a35c86b35f64dc1dd915ad44f3 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Eike Ziller <eike.ziller@digia.com> Reviewed-by: Jake Petroules <jake.petroules@petroules.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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-142-10/+5
| | | | | | | | | | 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>
* qmake: Pick up default bundle prefix from Xcode preferencesTor Arne Vestbø2013-10-311-0/+9
| | | | | | | | | But still fall back to 'com.yourcompany', just like Xcode does for the initial launch. Change-Id: I89afadefafc254a0014aca197741d42a0199943e Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
* xcode: Set QMAKE_XCODE_LIBRARY_SUFFIX from default_postTor Arne Vestbø2013-10-252-2/+3
| | | | | | | | | 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>
* Xcode: Dynamically choose release/debug libs based on current configurationTor Arne Vestbø2013-10-161-0/+6
| | | | | | | | | | | | | | Non-framework builds would automatically link to whatever Qt library matched the config at the time of running qmake, eg hard-coded to libQtCore_debug, while Xcode itself allowed the user to switch between release and debug configurations. We now append an Xcode settings variable to the library path, which gets resolved at build time depending on the current config in Xcode. Change-Id: I12873e38a28d9595ef3fd0ae0ad849e6744833a9 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Andy Shaw <andy.shaw@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>
* Merge remote-tracking branch 'origin/release' into stableFrederik Gladhorn2013-06-251-5/+8
|\ | | | | | | Change-Id: I4c0ae2ac1c10d4d50c03625c802d981b7850ed6f
| * 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>
* | Scope cached Mac SDK tool values by mkspecTor Arne Vestbø2013-06-241-3/+6
|/ | | | | | | | Otherwise doing stuff like -spec macx-g++ when the default spec is clang will not have an effect on the tools used. Change-Id: Ia2769abfdd8c19f79d427b9f09707430e736305a Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
* Cache Xcode and SDK settings in .qmake.cache if it existsTor Arne Vestbø2013-05-083-8/+54
| | | | | | | | | | | | | | | 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>
* Harden check for SDK platform name on Mac OSTor Arne Vestbø2013-04-181-2/+2
| | | | | | | | | | We now use an absolute path, to prevent picking up the wrong plutil binary. In addition we pipe the possible stderr output of plutil and xpath to the null device, so that the final QMAKE_MAC_PLATFORM_NAME will be empty in case of any errors, and caught by the isEmpty() check below. Change-Id: I8ad24bf63162a76410c2ae223dd2fc48e7886bbf Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
* Use absolute paths for Xcode helpers such as xcodebuild/xcrun/xcode-selectTor Arne Vestbø2013-04-091-2/+2
| | | | | | | | | | | We always use the xcodebuild/xcrun/xcode-select binaries in /usr/bin, as these will dispatch to the right binary based on what Xcode version has been chosen using xcode-select -switch. This fixes an issue where a tool was in the path from another Xcode installation. We can rely on the tools as they are present on a clean Mac OS install. Change-Id: I1d3cc1e92604f9be6d6f14639cb6322234edd696 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
* Handle errors when sysrooting tools on MacTor Arne Vestbø2013-04-081-1/+3
| | | | | | | | | | xcrun will spit out errors to stderr and nothing to stdout if it fails to find the tool in question. By checking for an empty return value and skipping the sysrooting we guard against mangling the tool variable. Change-Id: I68f59a6c8116696dd75cceed7b33ac666f3468b2 Reviewed-by: Eike Ziller <eike.ziller@digia.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
* Enable C++11 on OSX when using ClangTor Arne Vestbø2013-04-051-0/+3
| | | | | | | | | | | | | | This means we have to bump the deployment target to Lion (10.7), as the LLVM 'libc++' C++ standard library does not support Snow Leopard (10.6). For iOS the deployment target has to be bumped from 4.3 to 5.0, but we don't enable C++11 by default yet as it's not tested enough on iOS. Users who wish to deploy to 10.6 need to build their own Qt, passing -no-c++11 to configure. Change-Id: I7b5d20ab002db889d1091a4b7ff600f62caa7f06 Reviewed-by: Morten Johan Sørvig <morten.sorvig@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>
* Use tools from the SDK's toolchain instead of the ones in /usr/binTor Arne Vestbø2013-03-131-0/+9
| | | | | | | | | | | | | | | | | | | | For Mac OS X we currently specify build tools without an absolute path, which means we end up using the ones in /usr/bin. This is wrong, we should be using the tools from the toolchain of the chosen SDK. For iOS we do specify an absolute path, by resolving the toolchain path in the iOS makespecs. To solve the situation on Mac OS X, we move the logic of resolving the toolchain path to sdk.prf, and share it between OSX and iOS. For configure we need to duplicate some of the logic from sdk.prf, as configure pulls out QMAKE_CC and QMAKE_CXX for running some initial tests and building qmake. The new macSDKify function also solves the issue of missing sysroot and deployment version in the flags. Change-Id: Ib1d239c9904cf3ccee5214b313cf6205869a1462 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
* Simplify how we resolve the SDK root on Mac OSTor Arne Vestbø2013-03-131-7/+2
| | | | | | | | | | We now take advantage of the fact that xcodebuild -version allows you to pass the key that you're interested in, to only print that single value. This technique is used by Apple's own build scripts as well. Change-Id: I57b8424590d4137a0e7f263a318e17ee2e0dfad4 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* Make host_build re-use the sdk.prf logicTor Arne Vestbø2013-03-021-28/+24
| | | | | | | | | | | | Instead of hard-coding the SDK and deployment target. A host build will already use the host-makespec, so now that we always build against an SDK, these mkspecs will have the SDK and deployment target set. Change-Id: I2b0343ae75f7de12081bab8346307b96b3883f62 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Merge "Merge branch 'ios' into dev" into refs/staging/devTor Arne Vestbø2013-02-281-1/+9
|\
| * iOS: Replace device and simulator makespecs with single makespecTor Arne Vestbø2013-02-271-1/+9
| | | | | | | | | | | | | | | | | | | | And use configure's -sdk argument to choose between the iphoneos and the iphonesimulator SDK. xcodebuild -showsdks can be used to list the available SDKs. Passing an SDK without a version postfix implies the latest version of the SDK. Change-Id: I881df754d522fc91aaa16ba3e39cf0c37a21a1f1 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* | Don't look up DOCTYPE when resolving SDK settings on Mac OSTor Arne Vestbø2013-02-281-0/+1
|/ | | | | | | | | We don't want to hit the network, as a flakey network or slow server will hang the XML parsing. We assume the XML is well formed. Change-Id: Idc4898a925a46222954bf633a04ea9fe148c6797 Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
* Use sdk.prf to set macosx-version-min instead of static conf filesTor Arne Vestbø2013-02-221-0/+20
| | | | | | | | | | | | | Allows us to dynamically generate the command line option for iOS later, and allows the user to override QMAKE_MACOSX_DEPLOYMENT_TARGET with the expected effect on the command line options. We unset PERL5LIB to ensure we get the system Perl libraries, since the Mac OS 10.6 CI machine seems to have a broken XML::Parser::Expat from macports/CPAN. Change-Id: I04430c7b1daf9452d72f9a04a6b7f8d0d6926884 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
* Clean up how we build against SDKs on Mac OSTor Arne Vestbø2013-02-191-6/+22
| | | | | | | | | | | | | | | Instead of setting -isysroot in both arch.test, compile.test, the various mkspecs, and sdk.prf, we now propgate the chosen SDK as the qmake variable QMAKE_MAC_SDK, which is then handled exclusivly in sdk.prf. The QMAKE_MAC_SDK variable, and -sdk argument to configure, is expected to be of the short-form name, eg macosx or iphoneos, not a full path, as that's what Xcode also expects. We take care of translating that into a full path for -isysroot/-syslibroot in sdk.prf, using xcodebuild as a helper. Change-Id: I281655b2fa5180c6e78ffdce36824e4a91447570 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
* configure: Remove the -dwarf2 argument for Mac OS X buildsBradley T. Hughes2012-05-111-6/+0
| | | | | | | | | | Modern versions of Xcode properly support dwarf2, and as such dwarf2 is always enabled. This change removes the ability to turn it off, making dwarf2 non-optional. Change-Id: I149daeae6048ee8a1ed116363572173ad219102e Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
* Remove all usages of "arch" CFLAGS on Mac.Morten Johan Sorvig2012-05-044-28/+0
| | | | | | | | | | | | | Remove all [PPC|PPC64|X86|x86_64] CFLAGS, CXXFLAGS and OBJECTIVE_CFLAGS. Delete the arch prf files. 32/64 bit arch selection will be made using a different mechanism in Qt 5. Universal builds are not supported. Change-Id: I4664f2c31801cec7fb4d240f41c2c5204a109020 Reviewed-by: James Turner <james.turner@kdab.com> Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Initial import from the monolithic Qt.Qt by Nokia2011-04-2710-0/+101
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-27 04:40:53 +0000