Per earlier discussions we bump the deployment target for LTS releases
and follow up by requiring the latest SDK available for building.
As layer backed views and dark mode is a lot more stable these days in
Qt and on macOS in general we no longer support the option to build with
the 10.13 SDK. A workaround in case this functionality is still needed
is to explicitly set the QMAKE_MAC_SDK_VERSION qmake variable, which
will tell the linker to write that version into the MachO header of
the executable, which will then be read by AppKit when determining
which features to opt in to.
Change-Id: Ied4f6d75b710505a5c440c990b82567bea780db6
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
As planned, we only support the latest and previous release for these
platforms, and by the time 5.12 is out these platforms will all have
had new releases, so we should bump the deployment target now.
Change-Id: Ibbb7d07bb5d9a1007ab37b88d75781be2c1f7075
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
[ChangeLog][iOS] The minimum deployment target for applications is now
iOS 10.0.
Change-Id: Icb37e4eaecbf6f62fd3c9293b2abf19a0954a02d
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
The macOS and iOS version bumps were already proposed, and bumping
up tvOS and watchOS by one version since all original devices that
ran tvOS 9 and watchOS 1 can run the latest versions and given
the upgrade cycles and TP status of these platforms in 5.8, there
is not much point supporting any older version.
Change-Id: Ib01035054291f5bcd18d15a4f27ad33922076851
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
This reduces unnecessary OS conditions in qmake since these platforms
are mutually exclusive, and also opens up their potential for use on
future devices (like carOS(?), which is device idiom '5').
This is also more similar to what Xcode does, as the
TARGETED_DEVICE_FAMILY variable is not platform specific.
Change-Id: I29d209cd8e0779f492bda829008264773e13c75c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
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>
These actually affect all UIKit platforms (tvOS, watchOS), not just iOS.
Change-Id: I2b45ebecb10d11e33d301071093b5342ce101816
Reviewed-by: Mike Krus <mike.krus@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
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>
With iOS 6.0 and above the LC_MAIN load command is available, which allows
dyld to call the application entrypoint directly instead of going through
_start in crt.o. By passing -e to the linker we can change this entrypoint
to our wrapper that sets up the separate stack before entering the native
iOS runloop through UIApplicationMain. As before, we call the user's main()
from applicationDidFinishLaunching.
By using LC_MAIN instead of messing with the object files we open up the
possibility of generating Bitcode instead of object code, which can be
useful for link-time optimizations, either locally or by Apple.
Change-Id: If2153bc919581cd93dfa10fb6ff1c305b3e39a52
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
AppStore validation requires deployment target to be
at least 5.1.1 for 64-bit applications.
Change-Id: I4d857ad983e6d4059f541bff523dd63479aca849
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
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>
Apple only provides simulators for 5.0+, and we now rely on 5.0+ APIs.
Change-Id: I9ec047767b5f5e1b33aeef186ec6aff2b9c70a05
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
It's a supported platform from 5.2, and we want build-scripts/CI/etc to
adapt to the change as soon as possible.
Change-Id: I8c78351191f59a6ecab33acc0829d2535379c787
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Simo Fält <simo.falt@digia.com>
