AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
c311815592
qt5base-lts/mkspecs/macx-ios-clang/features/default_post.prf

98 lines
4.1 KiB
Plaintext
Raw Normal View History

iOS: Make Xcode output the default for GUI applications As long as Qt Creator does not provide any iOS integration, and the app bundle we create using the Makefile generator is not good enough to deploy to a device anyways, producing Xcode projects make the most sense. We base the decicion on whether or not the project depends on QtGui and has app_bundles enabled. This prevents configure tests and other tools from having Xcode projects, but allows examples and demos to build out of the box. Instead of setting the generator unconditionally we unset it in default_pre so that we can detect if the user set it manually. This means the user won't be able to inspect the MAKEFILE_GENERATOR variable from the pro file, but this is less of a use-case then overriding the generator from the command line or prooject file. Change-Id: I881cf3e29631445f83ea4ff0979f7a566e4810f5 Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2012-11-23 12:26:50 +00:00
iOS: Refactor default_post logic into more appropriate units The logic was lumped together in one big file. Now that things are more stable and the logic has proven to work over time we can split it out into the more appropriate sub-prfs. Change-Id: I9a40ad72ad9d7550b609e7f50fade1049dfa3ac1 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
2015-06-15 15:56:23 +00:00
equals(TEMPLATE, app):contains(CONFIG, qt) {
iOS: Always use application bundle when building Qt applications Change-Id: I8fd0f7b43bdcbff0bff2de890fe421eb51233192 Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
2013-09-26 15:00:19 +00:00
# If the application uses Qt, it needs to be an application bundle
# to be able to deploy and run on iOS. The only exception to this
# is if you're working with a jailbroken device and can run the
# resulting binary from the console/over SSH, but that's not a
# use-case we care about, so no need to complicate the logic.
iOS: Refactor default_post logic into more appropriate units The logic was lumped together in one big file. Now that things are more stable and the logic has proven to work over time we can split it out into the more appropriate sub-prfs. Change-Id: I9a40ad72ad9d7550b609e7f50fade1049dfa3ac1 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
2015-06-15 15:56:23 +00:00
CONFIG *= app_bundle
# For Qt applications we want Xcode project files as the generated output,
# but since qmake doesn't handle the transition between makefiles and Xcode
# project files (which happens when using subdirs), we can't just override
# MAKEFILE_GENERATOR. Instead, we generate the Xcode project by spawning a
# child qmake process with -spec macx-xcode and let the top level qmake
# process generate a wrapper makefile that forwards everything to xcodebuild.
equals(MAKEFILE_GENERATOR, UNIX): \
CONFIG = xcodebuild $$CONFIG
iOS: Make Xcode output the default for GUI applications As long as Qt Creator does not provide any iOS integration, and the app bundle we create using the Makefile generator is not good enough to deploy to a device anyways, producing Xcode projects make the most sense. We base the decicion on whether or not the project depends on QtGui and has app_bundles enabled. This prevents configure tests and other tools from having Xcode projects, but allows examples and demos to build out of the box. Instead of setting the generator unconditionally we unset it in default_pre so that we can detect if the user set it manually. This means the user won't be able to inspect the MAKEFILE_GENERATOR variable from the pro file, but this is less of a use-case then overriding the generator from the command line or prooject file. Change-Id: I881cf3e29631445f83ea4ff0979f7a566e4810f5 Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2012-11-23 12:26:50 +00:00
}
iOS: Refactor default_post logic into more appropriate units The logic was lumped together in one big file. Now that things are more stable and the logic has proven to work over time we can split it out into the more appropriate sub-prfs. Change-Id: I9a40ad72ad9d7550b609e7f50fade1049dfa3ac1 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
2015-06-15 15:56:23 +00:00
load(default_post)
iOS: Wrap Xcode projects in Makefile for convenience and subdirs support qmake expects the generator to be the same for each node in the tree of subdirs, including the leaf projects, which caused failures when qmake tried to recurse out to the leaf projects and run 'make', when the leaf project was an Xcode project. We now wrap the Xcode project in a meta-makefile that just calls out to xcodebuild to do the actual work. This allows us to get rid of the hacky generator detection, and use the macx-xcode mkspec instead of setting the generator, which is much cleaner. Change-Id: I2fed6a4dd6343b6a320eb459ecae824553bff459 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2013-06-27 10:02:05 +00:00
macx-xcode {
iOS: Target both iPhone and iPad by default Change-Id: I3122b9391c6187da17389c889a456c58210dca09 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2012-12-06 14:29:05 +00:00
ios_device_family.name = TARGETED_DEVICE_FAMILY
ios_device_family.value = $$QMAKE_IOS_TARGETED_DEVICE_FAMILY
QMAKE_MAC_XCODE_SETTINGS += ios_device_family
iOS: Provide default launch image for 4-inch devices Otherwise the application will not scale to the full resolution of the device. We copy the image into the Xcode project, since it's internal to our build system and not meant as a template to be edited by the user. For 5.3 we need to provide a proper qmake/qbs mechanism to handle launch images. Task-number: QTBUG-31431 Change-Id: Ied0b2843a78c5ea865750e0404418ced7ad27082 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
2013-11-26 12:40:21 +00:00
iOS: add AppIcon asset name to Xcode project The current work-flow for adding app icons to an iOS app during deployment is not good. You basically need to specify that you want to use asset catalogs from within Xcode and add your icons there. The problem is that qmake will regenerate the Xcode project the next time it runs, and your changes will then be lost. This patch will check if the project has a valid asset catalog assigned to QMAKE_BUNDLE_DATA, and configure the Xcode project to use it for app icons. Change-Id: I06621ca46aad91de96cb23ba8ca3b1a3f1226670 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
2015-01-07 12:49:52 +00:00
# If QMAKE_BUNDLE_DATA contains an asset catalog that includes an
# AppIcon.appiconset, we configure Xcode to use it for app icons.
for(bundle_data, QMAKE_BUNDLE_DATA) {
for(bundle_file, $${bundle_data}.files) {
!contains(bundle_file, .*\.xcassets$): next()
!exists($$absolute_path($$bundle_file/AppIcon.appiconset, $$_PRO_FILE_PWD_)): next()
asset_catalog_appicon.name = "ASSETCATALOG_COMPILER_APPICON_NAME"
asset_catalog_appicon.value = "AppIcon"
QMAKE_MAC_XCODE_SETTINGS += asset_catalog_appicon
break()
}
!isEmpty(asset_catalog_appicon.name): break()
}
iOS: Provide default launch image for 4-inch devices Otherwise the application will not scale to the full resolution of the device. We copy the image into the Xcode project, since it's internal to our build system and not meant as a template to be edited by the user. For 5.3 we need to provide a proper qmake/qbs mechanism to handle launch images. Task-number: QTBUG-31431 Change-Id: Ied0b2843a78c5ea865750e0404418ced7ad27082 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
2013-11-26 12:40:21 +00:00
# Set up default 4-inch iPhone/iPod launch image so that our apps
# support the full screen resolution of those devices.
iOS: ensure we don't overwrite a projects qmake variables Consider a project that does the following: launch_images.files = $$PWD/LaunchImage.xib QMAKE_BUNDLE_DATA += launch_images In that case we end up overwriting launch_images.files in default_post, and at the same time, add launch_images a second time to QMAKE_BUNDLE_DATA. The result will be that we copy our own launch image twize into the bundle. To prevent this, prepend our internal variables with qmake_ Change-Id: I24f870874017b5388248e3bfadecd461422ffe35 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
2015-07-27 13:27:07 +00:00
qmake_launch_image = Default-568h@2x.png
qmake_copy_image.input = $$QMAKESPEC/$$qmake_launch_image
qmake_copy_image.output = $$OUT_PWD/$${TARGET}.xcodeproj/$$qmake_launch_image
qmake_copy_image.CONFIG = verbatim
QMAKE_SUBSTITUTES += qmake_copy_image
qmake_launch_images.files = $$qmake_copy_image.output
QMAKE_BUNDLE_DATA += qmake_launch_images
iOS: let qmake generate default LaunchScreen.xib iOS8 will check if the app has a LaunchScreen.xib to determine if it supports iPhone6/6+ (scale factor and resolution). So we follow the same pattern as we do with the launch image for iPhone5, and generate a default LaunchScreen.xib. The xib file in this patch is a copy of a default file generated by a native Xcode project (with quotes escaped), but with the text label set to be $$TARGET. Change-Id: I163ab48b6f4edea4cc1f6840a1f3d8b3cc0326db Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
2014-11-03 10:23:05 +00:00
macx-ios-clang: only provide default LaunchScreen.xib if using Xcode 6 If using an older version of Xcode, Xcode will sometimes complain that LaunchScreen.xib uses auto layout while the project at the same time has deployment target set to 5.0 (where auto layout is not supported). This is a bug in Xcode really, since LaunchScreen.xib will only be used when running on iOS 7 (otherwise a LaunchImage will be used). This has been fixed in Xcode 6. This patch adds a check for this early on. Change-Id: Ie612c25b413add23e15fc3cb4f9e30bb5292369d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
2014-11-27 11:58:42 +00:00
lessThan(QMAKE_XCODE_VERSION, "6.0") {
warning("You need to update Xcode to version 6 or newer to fully support iPhone6/6+")
} else {
# Set up default LaunchScreen to support iPhone6/6+
iOS: ensure we don't overwrite a projects qmake variables Consider a project that does the following: launch_images.files = $$PWD/LaunchImage.xib QMAKE_BUNDLE_DATA += launch_images In that case we end up overwriting launch_images.files in default_post, and at the same time, add launch_images a second time to QMAKE_BUNDLE_DATA. The result will be that we copy our own launch image twize into the bundle. To prevent this, prepend our internal variables with qmake_ Change-Id: I24f870874017b5388248e3bfadecd461422ffe35 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
2015-07-27 13:27:07 +00:00
qmake_launch_screen = LaunchScreen.xib
qmake_copy_launch_screen.input = $$QMAKESPEC/$$qmake_launch_screen
qmake_copy_launch_screen.output = $$OUT_PWD/$${TARGET}.xcodeproj/$$qmake_launch_screen
QMAKE_SUBSTITUTES += qmake_copy_launch_screen
qmake_launch_screens.files = $$qmake_copy_launch_screen.output
QMAKE_BUNDLE_DATA += qmake_launch_screens
macx-ios-clang: only provide default LaunchScreen.xib if using Xcode 6 If using an older version of Xcode, Xcode will sometimes complain that LaunchScreen.xib uses auto layout while the project at the same time has deployment target set to 5.0 (where auto layout is not supported). This is a bug in Xcode really, since LaunchScreen.xib will only be used when running on iOS 7 (otherwise a LaunchImage will be used). This has been fixed in Xcode 6. This patch adds a check for this early on. Change-Id: Ie612c25b413add23e15fc3cb4f9e30bb5292369d Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
2014-11-27 11:58:42 +00:00
}
iOS: Target both iPhone and iPad by default Change-Id: I3122b9391c6187da17389c889a456c58210dca09 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2012-12-06 14:29:05 +00:00
}
iOS: Wrap Xcode projects in Makefile for convenience and subdirs support qmake expects the generator to be the same for each node in the tree of subdirs, including the leaf projects, which caused failures when qmake tried to recurse out to the leaf projects and run 'make', when the leaf project was an Xcode project. We now wrap the Xcode project in a meta-makefile that just calls out to xcodebuild to do the actual work. This allows us to get rid of the hacky generator detection, and use the macx-xcode mkspec instead of setting the generator, which is much cleaner. Change-Id: I2fed6a4dd6343b6a320eb459ecae824553bff459 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2013-06-27 10:02:05 +00:00
macx-xcode {
iOS: Set ARCHS in Xcode project for both simulator and device SDKs Removes the need to pass ARCHS to xcodebuild for simulator builds. Change-Id: If15e9d387c416c5c9f83c50f5903ae0cd517ff34 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2013-10-25 12:42:48 +00:00
arch_iphoneos.name = "ARCHS[sdk=iphoneos*]"
arch_iphoneos.value = $$QMAKE_IOS_DEVICE_ARCHS
arch_iphonesimulator.name = "ARCHS[sdk=iphonesimulator*]"
arch_iphonesimulator.value = $$QMAKE_IOS_SIMULATOR_ARCHS
QMAKE_MAC_XCODE_SETTINGS += arch_iphoneos arch_iphonesimulator
iOS: Ensure that the rename-main logic works for multi-arch builds We need to tell Xcode which architectures it should set up pre-link dependencies for, as well as run the rename script in the root object file directory. We pass it the current architectures so that we only rename main() for simulator or device, not both. Change-Id: I095d7c8a22ff0cb2ce872c9a86c93a070c1fcc65 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2014-11-06 15:14:32 +00:00
QMAKE_XCODE_ARCHS = $$QMAKE_IOS_DEVICE_ARCHS $$QMAKE_IOS_SIMULATOR_ARCHS
iOS: Tell Xcode to not build universal app binaries for debug builds You're likely to only target/develop on one device at a time, so we only need to build for one architecture at a time. Switching device in Xcode will switch the active architecture as well, so the only case where you'll need a universal debug build is if you are creating a debug package for testers. Change-Id: I4f37f5c982082c42836749d1e9fbe5ef91138912 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
2014-11-17 14:00:45 +00:00
only_active_arch.name = ONLY_ACTIVE_ARCH
only_active_arch.value = YES
only_active_arch.build = debug
QMAKE_MAC_XCODE_SETTINGS += only_active_arch
iOS: Don't mangle QT_ARCH when being more specific about what arch to build On iOS the compiler expects archs like armv6, armv7, armv7s when passed the -arch flag, or when the ARCHS Xcode variable is set. Instead of mangling QT_ARCH, which is used other places and assumed to match the values provided by the arch.test, we use our own variable. Change-Id: I05e10be8d69dd4d7cbcef04640fef99f1efb253d Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
2013-04-11 12:40:58 +00:00
} else {
iOS: Properly detect arm64 builds when choosing which -arch flags to pass Change-Id: Ib410584ba2c1fe342efb18eb955273090d36db8f Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Simon Hausmann <simon.hausmann@digia.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
2014-10-24 15:43:18 +00:00
# Be more specific about which architecture we're targeting
contains(QT_ARCH, arm.*): \
iOS: Allow ARCHS to be specified at build time for multi-arch builds Building all architectures of a multi-arch build during Qt development is in most cases not needed, so we expose a way to limit the archs we build by passing ARCHS="subset of archs" to make, similar to how you can pass ARCHS to xcodebuild. If the subset doesn't match any of the valid architectures for the target, it will fall back to the default architectures, so it's safe to pass eg. ARCHS="armv7 i386" to make, even if building for both simulator and device. The variable may also be exported to the environment for more persistent limits on which architectures to build. Change-Id: I47b10bc9d743f0301efff4181d6881ae140d557f Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2014-11-04 18:41:48 +00:00
VALID_ARCHS = $$QMAKE_IOS_DEVICE_ARCHS
iOS: Set ARCHS in Xcode project for both simulator and device SDKs Removes the need to pass ARCHS to xcodebuild for simulator builds. Change-Id: If15e9d387c416c5c9f83c50f5903ae0cd517ff34 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2013-10-25 12:42:48 +00:00
else: \
iOS: Allow ARCHS to be specified at build time for multi-arch builds Building all architectures of a multi-arch build during Qt development is in most cases not needed, so we expose a way to limit the archs we build by passing ARCHS="subset of archs" to make, similar to how you can pass ARCHS to xcodebuild. If the subset doesn't match any of the valid architectures for the target, it will fall back to the default architectures, so it's safe to pass eg. ARCHS="armv7 i386" to make, even if building for both simulator and device. The variable may also be exported to the environment for more persistent limits on which architectures to build. Change-Id: I47b10bc9d743f0301efff4181d6881ae140d557f Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2014-11-04 18:41:48 +00:00
VALID_ARCHS = $$QMAKE_IOS_SIMULATOR_ARCHS
iOS: Set ARCHS in Xcode project for both simulator and device SDKs Removes the need to pass ARCHS to xcodebuild for simulator builds. Change-Id: If15e9d387c416c5c9f83c50f5903ae0cd517ff34 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2013-10-25 12:42:48 +00:00
iOS: Enable fat builds containing both armv7 and arm64 slices Apple will from February 1, 2015, require all applications uploaded to the App Store to be built for both 32-bit (armv7/s) and 64-bit (arm64). https://developer.apple.com/news/?id=10202014a We enable fat Qt binaries by passing both -arch armv7 and -arch arm64 to clang, which takes care of lipoing together the two slices for each object file. This unfortunately means twice the build time and twice the binary size for our libraries. Since precompiled headers are architecture specific, and the -Xarch option can't be used with -include-pch, we need to disable precompiled headers globally. This can be improved in the future by switching to pretokenized headers (http://clang.llvm.org/docs/PTHInternals.html). Since we're enabling 64-bit ARM builds, we're also switching the simulator builds from i386 to fat i386 and x86_64 builds, so that we are able to test 64-bit builds using the simulator, but we're keeping i386 as the architecture Qt is aware of when it's building for simulator, as we need the CPU features to match the lowest common denominator. Change-Id: I277e60bddae549d24ca3c6301d842405180aded6 Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
2014-10-28 12:27:25 +00:00
single_arch: VALID_ARCHS = $$first(VALID_ARCHS)
iOS: Allow ARCHS to be specified at build time for multi-arch builds Building all architectures of a multi-arch build during Qt development is in most cases not needed, so we expose a way to limit the archs we build by passing ARCHS="subset of archs" to make, similar to how you can pass ARCHS to xcodebuild. If the subset doesn't match any of the valid architectures for the target, it will fall back to the default architectures, so it's safe to pass eg. ARCHS="armv7 i386" to make, even if building for both simulator and device. The variable may also be exported to the environment for more persistent limits on which architectures to build. Change-Id: I47b10bc9d743f0301efff4181d6881ae140d557f Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2014-11-04 18:41:48 +00:00
ACTIVE_ARCHS = $(filter $(EXPORT_VALID_ARCHS), $(ARCHS))
ARCH_ARGS = $(foreach arch, $(if $(EXPORT_ACTIVE_ARCHS), $(EXPORT_ACTIVE_ARCHS), $(EXPORT_VALID_ARCHS)), -arch $(arch))
QMAKE_EXTRA_VARIABLES += VALID_ARCHS ACTIVE_ARCHS ARCH_ARGS
arch_flags = $(EXPORT_ARCH_ARGS)
iOS: Don't mangle QT_ARCH when being more specific about what arch to build On iOS the compiler expects archs like armv6, armv7, armv7s when passed the -arch flag, or when the ARCHS Xcode variable is set. Instead of mangling QT_ARCH, which is used other places and assumed to match the values provided by the arch.test, we use our own variable. Change-Id: I05e10be8d69dd4d7cbcef04640fef99f1efb253d Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
2013-04-11 12:40:58 +00:00
QMAKE_CFLAGS += $$arch_flags
QMAKE_CXXFLAGS += $$arch_flags
QMAKE_LFLAGS += $$arch_flags
iOS: Move arch handling out of ios.prf now that we have default_post.prf Change-Id: Ifad6463414d4fb055007653d06f2c17ca5ee953e Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
2013-03-11 13:54:06 +00:00
}
Reference in New Issue Copy Permalink