summaryrefslogtreecommitdiffstats
path: root/mkspecs/features/mac
Commit message (Collapse)AuthorAgeFilesLines
* fix QMAKE_DEFAULT_*DIRS resolution with apple SDK, take 2Oswald Buddenhagen2016-10-163-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Get rid of simulator_and_device CONFIG option (mostly)Oswald Buddenhagen2016-10-161-1/+4
| | | | | | | | | | | | | | | | A separate flag is no longer needed now that simulator and device builds are not exclusive any more (*) - both 'simulator' and 'device' being set at the same time is a sufficient indication (uikit/default_pre.prf sets this up according to the simulator_and_device feature and the QMAKE_MAC_SDK variable). (*) xcodebuild mode actually still uses exclusive builds, but this is activated locally in uikit/default_post.prf, and uikit/xcodebuild.prf implements the actual build passes manually anyway, so this change does not affect it. Change-Id: Idf173a7bfeb984498d3a49ed6b8d1a16da6c2089 Reviewed-by: Jake Petroules <jake.petroules@qt.io>
* Merge remote-tracking branch 'origin/5.7' into 5.8Liang Qi2016-10-063-2/+113
|\ | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: mkspecs/features/mac/default_pre.prf mkspecs/features/qpa/genericunixfontdatabase.prf mkspecs/features/uikit/default_post.prf mkspecs/features/uikit/resolve_config.prf mkspecs/macx-ios-clang/features/default_post.prf mkspecs/macx-ios-clang/features/resolve_config.prf src/corelib/io/qiodevice.cpp Change-Id: I6f210f71f177a3c3278a4f380542195e14e4b491
| * Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-10-013-2/+113
| |\ | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: mkspecs/features/mac/default_pre.prf mkspecs/macx-ios-clang/features/resolve_config.prf qtbase.pro Change-Id: I65b5ebca4942a4f295bdd4ac1568e5c347333aea
| | * Add the ability for qmake to build Xcode asset catalogsJake Petroules2016-09-283-2/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This essentially emulates Xcode behavior for QMAKE_BUNDLE_DATA. This is mostly for our own internal use. No documentation is provided. Variables introduced: - QMAKE_ASSET_CATALOGS - QMAKE_ASSET_CATALOGS_APP_ICON - QMAKE_ASSET_CATALOGS_BUILD_PATH - QMAKE_ASSET_CATALOGS_INSTALL_PATH Change-Id: I9577415d637f022d05f301c5a0d799483cd2a963 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
| * | fix QMAKE_DEFAULT_*DIRS resolution with apple SDKOswald Buddenhagen2016-09-153-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 of this is that project files may not override QMAKE_MAC_SDK any more, which seems to be no big loss. it is still possible to override the sdk on the configure command line (but note that this only ever worked for the target sdk). it has also 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. Change-Id: I149e0540c00745fe8119fffd146283bb214f22ec Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | | Make DEVICE_ARCHS and SIMULATOR_ARCHS variables platform independentJake Petroules2016-09-051-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reduces unnecessary OS conditions in qmake since these platforms are mutually exclusive, and also opens up their potential for use on macOS to transparently support multi-arch builds like UIKit platforms. This is also more similar to what Xcode does, as the DEPLOYMENT_TARGET variables are platform specific, while the ARCHS variable is not. DEPLOYMENT_TARGET has a use case for being OS specific in qmake (host tools vs targets), while ARCHS does not. Change-Id: Icee838a39e84259c2089faff08cc11d5f849758d Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | | Remove simulator_and_device handling for the Makefile generatorJake Petroules2016-09-031-17/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch moves towards a more sensible layout for UIKit platforms, where both the device and simulator architectures for binaries are combined into a single Mach-O file instead of separating out the simulator architecutures into separate _simulator.a files. This approach is both more common in the iOS ecosystem at large and significantly simplifies the implementation details for Qt, especially with the upcoming support for shared libraries on UIKit platforms. This patch takes advantage of the -Xarch compiler option to pass the appropriate -isysroot, -syslibroot, and -m*-version-min compiler and linker flags to the clang frontend, operating in exactly the same way as a normal multi-arch build for device or simulator did previously. Exclusive builds are still enabled for the xcodebuild wrapper Makefile, which builds all four configurations of a UIKit Xcode project as before, as expected. A particularly advantageous benefit of this change is that it flows very well with existing Xcode workflows, namely that: - Slicing out unused architectures is handled completely automatically for static builds, as an executable linking to a library with more architectures than it itself is linked as, the unused architectures will be ignored silently, resulting in the same behavior for users (and the App Store won't let you submit Intel architectures either). - Removing architectures from a fat binary using lipo does NOT invalidate the code signature of that file or its container if it is a bundle. This allows shared library and framework builds of Qt to work mostly automatically as well, since an Xcode shell script build phase can remove unused architectures from the embedded frameworks when that is implemented, and if Qt ever starts signing its SDK releases, it won't interfere with that either (though binaries are just resigned). Change-Id: I6c3578c78f75845a2fcc85f3a5b728ec997dbe90 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | | Enable precompiled headers on iOS, tvOS, watchOSJake Petroules2016-09-021-5/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The actual blocker for precompiled headers is not the iOS/tvOS/watchOS platforms, but the way qmake handled multiple-architecture builds on Apple platforms. This patch allows multi-arch builds to be performed while using precompiled headers. Since df91ef3d6c55692a0236f67b6c6b134a3bf84098 (April 2009), Clang has had support for PCH files in the driver, which allows to use the -include flag to automatically translate to -include-pch. We can then take advantage of the fact that the -include option is allowed to not be separate from its argument, which lets us take advantage of -Xarch to specify a per-architecture precompiled header file. This is done through some magic in the qmake Makefile generator which "multiplexes" the PCH creation rule across multiple architectures and replaces a series of tokens with the proper precompiled header paths and architecture flags at usage point. Change-Id: I76c8dc9cda7e218869c2919f023d9b04f311c6fd Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | | Add support for Apple watchOSJake Petroules2016-08-191-0/+1
| | | | | | | | | | | | | | | Change-Id: I3f9e00569458a463af2eaa5a3a16a6afd1e9c1ea Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* | | Use qtConfig throughout in qtbaseLars Knoll2016-08-192-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge remote-tracking branch 'origin/5.7' into devEdward Welbourne2016-08-011-1/+1
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: configure 5.7 now supports clang on android; but dev re-worked configure src/gui/kernel/qevent.h One side renamed a parameter of a constructor; the other added an alternate constructor on the next line. Applied the rename to both for consistency. tests/auto/tools/moc/tst_moc.cpp Each side added a new test at the end. .qmake.conf Ignored 5.7's change to MODULE_VERSION. configure.json No conflict noticed by git; but changes in 5.7 were needed for the re-worked configure to accommodate 5.7's stricter handling of C++11. Change-Id: I9cda53836a32d7bf83828212c7ea00b1de3e09d2
| * | Merge remote-tracking branch 'origin/5.6' into 5.7Edward Welbourne2016-07-261-1/+1
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qtemporarydir.cpp One side encapsulated a repeated piece of #if-ery in a local define; the other added to the #if-ery. Made its addition to the other's. src/corelib/kernel/qeventdispatcher_unix_p.h One side moved some members into a struct; this collided with a #undef check that neither side now has. Discarded the #undef part. src/gui/opengl/qopengltexturehelper_p.h 5.7 deleted a bunch of methods; not clear why merge got confused. src/tools/moc/moc.cpp One added a name to the copyright header; another changed its URL. Change-Id: I9e9032b819f030d67f1915445acf2793e98713fa
| | * configure and mkspecs: Don't try to find xcrun with xcrunGabriel de Dietrich2016-07-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since Xcode 8 (beta 2) that tool is no longer available through xcrun. We resort to xcodebuild instead. Change-Id: If9d7b535c1cbac2caae0112b2003283aeff34fb9 Reviewed-by: Jake Petroules <jake.petroules@qt.io> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | | Add support for Apple tvOSMike Krus2016-05-171-2/+3
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass -xplatform macx-tvos-clang to configure to build. Builds device and simulator by default. Added ‘uikit’ platform with the common setup. Also added QT_PLATFORM_UIKIT define (undocumented). qmake config defines tvos (but not ios). tvOS is 64bits only (QT_ARCH is arm64) and requires bitcode to be embedded in the binary. A new ‘bitcode’ configuration was added. For ReleaseDevice builds (which get archived and push to the store), bitcode is actually embedded (-fembed-bitcode passed to clang). For all other configurations, only using bitcode markers to keep file size down (-fembed-bitcode-marker). Build disables Widgets in qtbase, and qtscript (unsupported, would require fixes to JavaScriptCore source code). Qpa same as on iOS but disables device orientation, status bar, clipboard, menus, dialogs which are not supported on tvOS. Change-Id: I645804fd933be0befddeeb43095a74d2c178b2ba Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* | xcodeSDKInfo: return the correct path based on the specified SDK.Jake Petroules2016-02-181-1/+1
| | | | | | | | | | | | | | | | This fixes a regression introduced in 9daeb6fe9d35b10ed739ea0a0566533524ffd532. Change-Id: I3100b307bb65c90bdc023be4993afaea666e409d Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | Generalize iOS simulator and device exclusive buildTor Arne Vestbø2016-02-121-33/+23
|/ | | | | | | | Preparation for Apple tvOS support, which shares a lot with the iOS platform. Change-Id: I543d936b9973a60139889da2a3d4948914e9c2b2 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* Add tool to namespace Objective-C classes at link timeTor Arne Vestbø2016-01-291-0/+50
| | | | | | | | | | | | | | | | | | The feature is enabled by CONFIG += unsupported/objc_namespace, but can be easily integrated into other build systems such as CMake or native Xcode by modifying the LD and LDFLAGS equivalent for each build system. This is a less resource-intensive alternative to using multiple Qt builds with different -qtnamespace settings. Note: The feature is not supported in any way, and should be used with care. Change-Id: Ibb8ba1159db36efd7106c117cc2210c7e2e24784 Reviewed-by: Martin Smith <martin.smith@theqtcompany.com> Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* Distinguish between Objective-C and Objective-C++ sourcesTor Arne Vestbø2015-10-092-22/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of lumping both Objective-C (.m) and Objective-C++ (.mm) sources into the same pile, passing them on to the same compiler as for C++ (CXX), with the C++ flags (CXXFLAGS), we follow Apple's lead and treat them as variants of the C and C++ languages separately, so that Objective-C sources are built with CC and with CFLAGS, and Objective-C++ sources with CXX, and CXXFLAGS. This lets us remove a lot of duplicated flags and definitions from the QMAKE_OBJECTIVE_CFLAGS variable, which in 99% of the cases just matched the C++ equivalent. The remaining Objective-C/C++ flags are added to CFLAGS/CXXFLAGS, as the compiler will just ignore them when running in C/C++ mode. This matches Xcode, which also doesn't have a separate build setting for Objective-C/C++ flags. The Makefile qmake generator has been rewritten to support Objective-C/C++ fully, by not assuming that we're just iterating over the C and C++ extensions when dealing with compilation rules, precompiled headers, etc. There's some duplicated logic in this code, as inherent by qmake's already duplicated code paths, but this can be cleaned up when C++11 support is mandatory and we can use lambda functions. Task-number: QTBUG-36575 Change-Id: I4f06576d5f49e939333a2e03d965da54119e5e31 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
* Add detection of C++14 and C++1z compiler featuresThiago Macieira2015-09-051-3/+0
| | | | | | | | | | | | | | | [ChangeLog][General Improvements] Qt's buildsystem now detects whether the compiler supports C++14 and experimental support for C++1z. If the compiler supports it, then Qt is automatically compiled using that support. \ This does not apply to user applications built using qmake: those are still built with C++11 support only. To enable support for C++14 in your application, add to your .pro file: CONFIG += c++14 (similarly for C++1z). Change-Id: Ib056b47dde3341ef9a52ffff13ef1f5d01c42596 Reviewed-by: Lars Knoll <lars.knoll@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>
* qmake: Expose iOS/OS X SDK platform path as QMAKE_MAC_SDK_PLATFORM_PATHTor Arne Vestbø2015-03-061-0/+8
| | | | | | Change-Id: I2e58c22301a433208718c26b362b4dda2b891f0e Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* Decouple caching of iOS/OSX SDK path and version in sdk.prfTor Arne Vestbø2014-12-011-1/+5
| | | | | | | | | Combining them could lead to intermediate builds having cached the path, but not the version, resulting in later version checks failing. Change-Id: Ia10f4268ce7b9e82c81627970236d68c00b80391 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* mkspec macx-ios-clang: ensure SDK version is validRichard Moe Gustavsen2014-11-111-0/+4
| | | | | | | | | | | | | | | | | Ensure the sdk is of recent enough version since: 1. we build Qt with the latest sdk version, so the app needs to do the same to avoid compatibility problems e.g when linking. 2. using a launch screen to support iphone6 depends on sdk 8 3. Apple requires apps that are pushed to appstore to use the latest version of the sdk. Ideally we should store the sdk version used to build Qt, and require that apps use the same version or newer. But this patch will do until that is in place. Change-Id: I18b06d09c1eda15122975b7169ca7a3372df6054 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.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-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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-04 00:30:27 +0000