summaryrefslogtreecommitdiffstats
path: root/mkspecs/features/mac/default_post.prf
Commit message (Collapse)AuthorAgeFilesLines
* Add preliminary support for Qt for visionOSTor Arne Vestbø2024-04-181-8/+16
| | | | | | | | | | | | | | | | | | | | | | Qt already runs on Vision Pro as "Designed for iPad", using Qt for iOS. This change enables building Qt for visionOS directly, which opens the door to visionOS specific APIs and use-cases such as volumes and immersive spaces. The platform removes some APIs we depend on, notably UIScreen, so some code paths have been disabled or mocked to get something up and running. As our current window management approach on UIKit platforms depends on UIWindow and UIScreen there is currently no way to bring up QWindows. This will improve once we refactor our window management to use window scenes. To configure for visionOS, pass -platform macx-visionos-clang, and optionally add -sdk xrsimulator to build for the simulator. Change-Id: I4eda55fc3fd06e12d30a188928487cf68940ee07 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Warn when configuring Qt with an unsupported Apple SDK or XcodeAlexandru Croitor2023-11-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The warnings are shown when configuring any Qt submodule or top-level. The warnings are NOT shown when configuring a user project with CMake. Opt out CMake cache variables can be set to silence any of the warnings: - QT_NO_APPLE_SDK_AND_XCODE_CHECK - QT_NO_APPLE_SDK_MIN_VERSION_CHECK - QT_NO_XCODE_MIN_VERSION_CHECK - QT_NO_APPLE_SDK_MAX_VERSION_CHECK The warnings can be upgraded into errors by configuring with -DQT_FORCE_FATAL_APPLE_SDK_AND_XCODE_CHECK=ON The platform version requirements that qtbase specifies in .cmake.conf are saved in Qt6ConfigExtras.cmake so that they can be used when configuring other non-qtbase submodules. The code is added to the public CMake files, so that in the future we don't need to move code around if we enable the checks for public CMake projects as well. The version extraction helpers were moved out of QtAutoDetectHelpers into QtPublicAppleHelpers. Task-number: QTBUG-119490 Change-Id: Ic840e1013aeb607bf23247a9cb43471dde802e9d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
* CMake: remove tests for C++17 and C11 and earlierThiago Macieira2023-03-211-23/+0
| | | | | | | | | | | | Qt requires them and will fail to build if it isn't met, so we don't need to check for its support. These were public CMake and qmake features, so to keep compatibility with existing they're hardcoded now (only done for the C++ editions and for qmake only, as that's what Qt 5 did). Change-Id: I7f354474adce419ca6c2fffd174814724f45f90b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Guard some qmake 'simulator' conditions with iOS scopeTor Arne Vestbø2022-10-051-4/+4
| | | | | | Fixes: QTBUG-106353 Change-Id: Ic5a7aa1b9d932d0cb50a6c0924eb1a9a0d93cf38 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* qmake: Fix non-Xcode asset catalog handling for iOS simulatorAlexandru Croitor2022-08-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | If an iOS project was built with qmake using the Makefile generator instead of the Xcode generator, so -spec macx-ios-clang, and not -spec macx-xcode, Asset catalog processing failed with an actool error like Unknown platform: "ios-simulator" This is because we used the deployment identifier (which is meant for creation of the -mios-simulator-version-min flag) to pass a value to actool's -platform option, rather than the sdk name. Introduce a new variable called platform_identifier, which will be set to the currently processed macOS/iOS sdk name (e.g. macosx, iphonesimulator, iphoneos). Use it when processing asset catalogs using the Makefile generator. Relates to 9daeb6fe9d35b10ed739ea0a0566533524ffd532 Amends 5574aa986b69277881fe5fc694d97514c668024f Pick-to: 6.3 6.4 Fixes: QTBUG-102053 Change-Id: Ic4ea3b9e11c21ae535d6544cbed3670f9db44e72 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Fix version number when warning about Apple platform SDK mismatchTor Arne Vestbø2021-11-031-1/+1
| | | | | | Pick-to: 6.2 5.15 Change-Id: I9b9cda0c6bb9ad527dbf4b4268c1b572aa04d164 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Respect QMAKE_APPLE_DEVICE_ARCHS by building for all those archsTor Arne Vestbø2021-06-231-8/+18
| | | | | | | | | | If QMAKE_APPLE_DEVICE_ARCHS is not set, we pick up the available archs based on what Qt was built with (QT_ARCS), but only build the active arch. Pick-to: 6.2 Change-Id: I83273f878022af34a3a0d0eeae8b11d781f78c49 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* qmake: Pick default architecture on macOS based on unameTor Arne Vestbø2021-05-211-6/+12
| | | | | | | | | | | | | | | | | | | | | | | When dealing with a universal build of Qt, we would end up using the QT_ARCH as the architecture for user projects, but this architecture is always the primary one that Qt was configured with. Instead of relying on QT_ARCH, we start writing QT_ARCHS (plural) to qconfig.pri, based on CMAKE_OSX_ARCHITECTURES, and then use that to initialize QMAKE_APPLE_DEVICE_ARCHS. We then resolve the active arch using uname -m, matching what CMake does. We still feed all the available architectures to the Makefile or Xcode project, so that the user can build for any of the available architectures without needing a reconfigure. Fixes: QTBUG-93760 Change-Id: I0d338241ba4d944ca36d85371e9c4df7dbc4f269 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* qmake: Improve error message when detecting macOS platform SDK upgradeTor Arne Vestbø2021-03-191-1/+6
| | | | | | | Pick-to: 6.1 6.0 5.15 Task-number: QTBUG-85546 Change-Id: I2bce9d22ad826fa73fa4dbfd03c9b1d404c57859 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* macOS: Only check SDK major version for compatibilityTor Arne Vestbø2021-01-201-2/+2
| | | | | | | | | The macOS SDKs now follow the same major/minor version scheme as iOS, where the major version is bumped for each OS release. Pick-to: 6.0 5.15 Change-Id: I021421a9c58bb1ae64bc0c63b4215f14e4ada358 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* macOS: Don't hard-code x86_64 as the architecture when using qmakeTor Arne Vestbø2020-12-071-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The qmake variable QMAKE_APPLE_DEVICE_ARCHS was added for iOS, to support universal builds, as the QT_ARCH is a single value. Since the qmake macOS builds are non-universal (at the moment), we remove the hard-coded value for QMAKE_APPLE_DEVICE_ARCHS on macOS, and let the normal architecture test resolve the arch, like on other platforms. To ensure that the following configuration tests are run with an -arch argument, we trigger a commit of the preliminary Qt configuration after running the architecture test. This is not strictly necessary, but makes it clearer what's going on during configure. The device_and_simulator configuration option was used by the iOS toolchain, and needed to be moved up in the configuration test order to not break later tests. The logic in mac/default_post.prf for both Xcode and Makefiles to add -arch flags was kept as is, based on the existing variable, to avoid too many changes to this logic. The logic in toolchain.prf was amended to make it clear and ensure that it only applies to iOS builds. macOS builds do not have this issue. Pick-to: 6.0 Pick-to: 5.15 Pick-to: 5.12 Change-Id: I70db7e4c27f0d3da5d0af33cb491d72c312d3fa8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Pass SDK root to the linker as -isysroot, not -Wl,-syslibrootTor Arne Vestbø2020-04-021-2/+2
| | | | | | | | | | | | | | | | | The former option to clang will result in more options to the linker, such as the newly introduced -platform_version, which writes the SDK version to the resulting binary. By using the syslibroot flag directly we were missing the platform version, and binaries were left without an SDK version set, resulting in failed validation of the binary. Going with the clang driver gives us the right behavior for free. Fixes: QTBUG-83100 Change-Id: I98bc9ba644dae4bcc7a6a88481556bae185ce5fa Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> (cherry picked from commit 6a60192ac03d0b4ab542191065122243cebcd1ca) Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Fix isysroot for simulator only builds on iosMichal Klocek2020-01-131-5/+8
| | | | | | | | | | When not doing fat builds, QMAKE_MAC_SDK_PATH defaults to iphoneos sysroot, which breaks compilation. This fixes compilation when user sets also CONFIG-=device Change-Id: I1d18269946cd2a5608e26d943159c824f31db09a Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Fix rpath on UIKit systemsTor Arne Vestbø2019-09-251-1/+2
| | | | | | Change-Id: I0b35c32f3730dc15d868b10489abeda909bbe926 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Xcode: Ensure there's always a CFBundle[Short]Version[String] setTor Arne Vestbø2019-09-231-15/+16
| | | | | | | | | 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>
* qmake: Quote path to project file in Xcode project Makefile ruleTor Arne Vestbø2019-08-201-1/+1
| | | | | Change-Id: I40aba757486548ef9f319d3176e89eb7129a007e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Allow specifying explicit SDK version on Apple platformsTor Arne Vestbø2019-08-081-1/+10
| | | | | | | | | | | 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>
* Pass qmake arguments when creating Xcode project from MakefileTor Arne Vestbø2019-08-011-1/+1
| | | | | Change-Id: I0020273b200465f44a135848b4fd505793e85c30 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Fix default rpath dirs on Apple platformsTor Arne Vestbø2019-01-151-1/+1
| | | | | | | | | | | | | | | | | | 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>
* macOS: Prevent checking for stale SDK without the required SDK nameTor Arne Vestbø2018-12-231-1/+1
| | | | | | | | | | | 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>
* escape literal backslashes in qmake filesOswald Buddenhagen2018-12-121-1/+1
| | | | | | Task-number: QTBUG-70765 Change-Id: I56abbf19be88d01b2964980fb741567f28e4f0fa Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add makefile target to generate Xcode projectTor Arne Vestbø2018-11-201-0/+7
| | | | | | | | | | 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>
* Merge remote-tracking branch 'origin/5.11' into 5.12.0Liang Qi2018-11-051-1/+1
|\ | | | | | | | | | | | | | | Conflicts: src/plugins/platforms/cocoa/qcocoaglcontext.mm src/plugins/platforms/xcb/qxcbscreen.h Change-Id: If9b4c67288396ff7346088ce591c7a3588b51979
| * macOS: Only detect changes to the SDK version within the same developer dirTor Arne Vestbø2018-10-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | macOS: Explicitly define lower bound for supported SDK versionTor Arne Vestbø2018-10-261-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | macOS: Only verify the major and minor version of the platform SDKTor Arne Vestbø2018-10-031-2/+4
| | | | | | | | | | | | Change-Id: I8de6c06e8be09483591efdf37c1631134d4ef826 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Andy Shaw <andy.shaw@qt.io>
* | macOS: Bump the SDK version we've tested with to 10.14Tor Arne Vestbø2018-10-031-4/+0
|/ | | | | Change-Id: Ibfdb8be91be46b22e0f0b97105121176a02a8576 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* macOS: Warn the user when using incompatible or untested platform SDKsTor Arne Vestbø2018-08-311-4/+36
| | | | | | Task-number: QTBUG-70263 Change-Id: Ic946d1efc69ebb8ba65bbba956ed55ab7183957e Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* macOS: Detect changes to the platform SDK and ask the user to deal with itTor Arne Vestbø2018-08-311-0/+6
| | | | | | | | | | | | | | 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>
* macOS: Use QMAKE_BUNDLE for the app part of the bundle identifier valueAndy Shaw2018-07-181-1/+4
| | | | | | | | | | | 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>
* Fix build of applications on iOSChristoph Keller2018-05-131-0/+7
| | | | | | | | | | | | 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>
* Rewrite the Info.plist variable replacement handlingJake Petroules2018-01-061-0/+23
| | | | | | | | | | 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>
* Allow using Xcode Command Line Tools to build QtJake Petroules2017-06-291-1/+2
| | | | | | | | | | | | | | 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>
* Only use -Xarch when specifying precompiled header if building multi archTor Arne Vestbø2017-06-121-1/+5
| | | | | | | | | | 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>
* 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>