All versions down to 6.2 require at least Xcode 12, which ships with
the macOS 11 SDK, and iOS 14 SDK.
Pick-to: 6.4 6.3 6.2
Change-Id: I128321ec9e97b670b7c027f1233978e1b8856f88
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
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>
Includes both minimum deployment targets and minimum sdk
versions.
As per supported Apple platforms versions which was done
in qt/qtdoc at
8807fdedce29cbbd7662fcd745234da30eace3fb
For Qt for iOS 6.0.x we only bump the minimum
deloyment target because applications seem to crash with iOS 12.4+,
and it's better to have a build error than a runtime error.
The minimum required sdk will not be bumped for 6.0.x, so we don't
accidentally break someone's existing build, given that 6.0 is already
released.
Pick-to: 6.1
Task-number: QTCREATORBUG-23574
Change-Id: I3046384164f2d7fdbd0cfd16dcb85e0d60bc56ce
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
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>
Testing seems to indicate building against the 11.0 SDK works fine,
and doesn't opt in to any new behaviors on Big Sur that Qt isn't
ready for.
Pick-to: 5.15
Pick-to: 5.12
Change-Id: I7da11cf25f2be7443c94ba7a4e9cd99dc1034455
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Apple deprecated the entire OpenGL API in favor of Metal, which
we are aware of, so we don't need to see the warnings when building
Qt.
Instead of applying the silencing globally for all Qt consumers,
both internal and external, we now limit the silencing to Qt itself.
That means user code that explicitly uses any of the deprecated APIs
will see the warnings. Note that this does not apply to merely using
any of the Qt OpenGL APIs. The user has to explicitly use the platform
APIs that have been deprecated.
The warnings need to be disabled on a build system level, so that
that they are passed as -D flags on the command line. If the defines
were done in Qt headers (qguiglobal.h e.g.), they would require the
user to always include this header before any of the Apple headers.
Change-Id: I3f2a2a5211332a059ad4416394251772c677fdcb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We will want to use C++17 code in our headers soon.
(including the one in the bootstrap libraries)
This patch is quick and dirty, I guess it will be cleaner once we move to cmake
Updated QMAKE_MACOSX_DEPLOYMENT_TARGET because 10.13 runtime does
not support C++17 stdlib features
Change-Id: I75ac171436945dddd1bb953a9c8d323ac20da7ac
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
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>
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>
As discussed earlier, we don't want to keep backwards compatibility
for more than two versions in addition to the current macOS version.
Change-Id: I24df6fb4a08e14a9f842d209b8e0a6079c533b65
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Add support for QSurface::VulkanSurface and QVulkanWindow.
Usage:
1) Build MoltenVK according to instructions
2) Configure Qt: ./configure -I /path/to/MoltenVK/Package/Release/MoltenVK/include
3) export QT_VULKAN_LIB=/path/to/MoltenVK/Package/Release/MoltenVK/macOS/libMoltenVK.
Implement support for QSurface::VulkanSurface by enabling
layer mode for QNSView and then creating a CAMetalLayer,
which the MoltenVK translation layer can run on.
MoltenVK provides an implementation of the Vulcan API,
which means that the platform integration is similar
to other platforms: implement a QCocoaVulkanInstance
where we pass the QNSView instance to the vkCreateMacOSSurfaceMVK
Vulkan surface constructor function.
Using Vulkan directly without QVulkanWindow is possible, but not
tested.
We currently load libMoltenVK at run-time and use the
existing QT_VULKAN_LIB environment variable to set its
path. For deployment purposes it would be better to
link against MoltenVK.frameworkm, but this
Task-number: QTBUG-66966
Change-Id: I04ec6289c40b199dca9fed32902b5d2ad4e9c030
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
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>
- Adapt to the OS X => macOS rename in Q_OS_ macros/docs, qmake scopes,
file selectors, etc.
- Add new QSysInfo values and MAC_OS_X / __MAC_ / __IPHONE_ values for
macOS 10.12 and iOS 9.1 through 10.0.
- Update prettyProductName with new macOS "Sierra" codename.
Change-Id: Id976530beeafa01b648ebaa16f4a8f0613fcaf75
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This gives us better consistency across the Qt ecosystem.
Change-Id: Ie12ebb6e8c826ed2e0445eb37de0b79595da41c2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Replace all tabs with proper space characters and consistently align
the '=' characters. The default alignment for the '=' of 25 characters
has been left as is to get a minimal diff. Lines with the '=' further
to the right and those belonging to 'proper code (TM)' have not been
touched.
The work was mostly done using the following python script (might
come in handy again...):
import sys, re
indent_eq = 25 + 0*4 # 25 characters was the most widely used indentation for the '=' character
p = re.compile(r'(\w+)[ \t]*([\-\+]?)(=$|= )[ \t]*(.*$)')
for fn in sys.argv[1:]:
with open(fn, 'r+') as f:
lines = []
nl_count = 0
continuity_indent = None
for l in f:
m = p.match(l)
nl = l
if m:
n_spaces = max(m.start(3), indent_eq - 1) - len(m.group(2)) - len(m.group(1))
if m.group(2) and m.start(2) >= indent_eq-1 and m.start(2) % 4 == 0:
n_spaces -= 1 # left-shift '+=' by one if the '+' is aligned to a multiple of 4
n_spaces = max(1, n_spaces) # we want at least one space before '='/'+='
nl = m.group(1) + ' '*n_spaces + ''.join(m.group(2,3,4)) + '\n'
continuity_indent = nl.find('= ') + 2 if l[-2] == '\\' else None # remember indent on '\\$'
elif continuity_indent:
nl = ' '*continuity_indent + l.lstrip()
if l[-2] != '\\': # check when to stop the continuation
continuity_indent = None
elif l.startswith('#'):
nl = l.expandtabs(2)
if l != nl:
nl_count += 1
lines.append(nl)
if nl_count > 0:
print fn, nl_count, len(lines)
f.seek(0)
f.writelines(lines)
f.truncate()
Change-Id: I1d2870d0a2fe2e30d398c140fe523e69dd20c81b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
The former applies both on Mac OS X and iOS, but 'macx' is specific to
Mac OS X.
ios.conf and macx.conf now share most of their settings in the common
mac.conf. We set the default QMAKE_MAC_SDK before loading mac.conf, so
that any overrides in the device config will apply afterwards. This
means configure's mkspec parsing will be able to read the QMAKE_MAC_SDK.
Change-Id: I0c7e26a6a0103e19b23ef152aa9e4ab461cee632
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
This is a step towards making mac a shared scope for both Mac OS X and
iOS, while macx is Mac OS X specific and ios is iOS specific.
We'll then move iOS to not include macx.conf, once we make the change
to not have iOS imply macx.
Change-Id: Ic9ce4d597873aa3cf2c981598354733e07db644d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
