Since the mkspecs always set QMAKE_APPLE_TARGETED_DEVICE_FAMILY, it will
never be empty, and the warning message and automatic fallback to
QMAKE_IOS_TARGETED_DEVICE_FAMILY will never be used.
Task-number: QTBUG-60430
Change-Id: I79e36d355dae3f8a4429d73e753fed3c090a5d24
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
This fixes an issue which caused certain iOS projects to fail to link
when building with Xcode, and also fixes an issue where projects were
only ever built with -fembed-bitcode instead of -fembed-bitcode-marker
for debug builds with the makefile generator.
Task-number: QTBUG-58754
Change-Id: Icf0c9f0d64dbc0b38d6c48bf635c5383a78bd6d5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
On Windows cd does not change the drive. So when you are on drive C:
and type "cd D:\data" it will change the directory on drive D: but not
affect your current working directory.
To also change your drive you have to provide the parameter /d on
Windows, so "cd /d D:\data" will also change the drive.
Task-number: QTBUG-57080
Change-Id: Ib629879534523982eec693cef725f20a535a1a74
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
The plugin depends on AssetLibrary.framework, which is only
available for iOS.
Change-Id: I798c87b57881210ced8e4a7399c1e45d130ee357
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
These CONFIG entries are also needed during configure, and preemptively
fixes build errors uncovered by an upcoming forward merge, due to code
restructuring.
Change-Id: I39ae5e0f24bbd43dd3c04225d42cce4edd199094
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
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>
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>
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).
this simplification is preparation for subsequent changes.
Change-Id: I3201629af132fa3938b13577854f3b19857a1b5a
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Instead of forcing a static build, configure now respects the
-shared flag and defaults to that.
[ChangeLog][Important Behavior Changes] Qt for iOS now respects the
-shared configure flag, and now defaults to this configuration as with
all other platforms.
Task-number: QTBUG-42937
Change-Id: I9e7b2de8f7f8ba031c2610ff5ac0858e357424bd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The "args" variable would contain the original -spec XXX flags in
addition to the -spec macx-xcode passed in the system command invocation
below. The last use of -spec takes effect, so this code was entirely
ineffective. Consequently, uikit/default_post.prf in the nested qmake
call thought it's still the top-level call and thus added xcodebuild
again, which caused an infinite recursion.
Change-Id: Ie98d8a7f3c1cd875f4a4146af9a66a66b48cc6cb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
26d44fce3d added support for passing the
configure options to qmake following a "--" argument. This interacted
badly with xcodebuild.prf as the "args" variable would contain the
standard qmake arguments AND the extra arguments following "--"... which
were placed prior to -spec macx-xcode and the path of the .pro file,
causing them to be ignored and thus qmake to print its usage when
attempting to generate Xcode projects for Qt apps on UIKit platforms.
Amends 6a9f38a11d, which fixed the same
issue inside qmake itself.
Change-Id: I3056bd811c2ce958952fec8e05ddef7a063c0646
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
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>
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>
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>
This is done because a followup patch will cause simulator_and_device builds
to no longer use exclusive builds and so this feature could not work,
but it is not strictly necessary anyways because users do not need to be
able to do this.
Done-with: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Change-Id: If869fbfea776751553c352c2d652edf745a3638d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
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>
we need to suppress another qtConfig(simulator_and_device) check during
the configuration phase.
amends 60985aa4.
Change-Id: Iae279d282d47b4c254b7a6f9f33315abe126eff0
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
cf53aa21bf and 3aaa5d6b32
were reverted because of reconstruction in 5.7.
defineTest(qtConfTest_checkCompiler) in configure.pri is smart
enough to cover the case in a9474d1260.
DirectWrite: Fix advances being scaled to 0
Since 131eee5cd, the stretch of a font can be 0, meaning
"whatever the font provides". In combination with ec7fee96,
this would cause advances in the DirectWrite engine to be scaled to
0, causing the QRawFont test to fail.
Conflicts:
configure
mkspecs/features/uikit/device_destinations.sh
mkspecs/features/uikit/xcodebuild.mk
src/corelib/global/qglobal.cpp
src/corelib/global/qnamespace.qdoc
src/plugins/platforms/cocoa/qcocoamenuitem.h
src/plugins/platforms/windows/qwindowsservices.cpp
src/plugins/platformthemes/gtk3/qgtk3dialoghelpers.cpp
src/plugins/platforms/windows/qwindowsfontenginedirectwrite.cpp
src/widgets/kernel/qapplication.cpp
tests/auto/widgets/dialogs/qfiledialog/tst_qfiledialog.cpp
tests/auto/widgets/dialogs/qfiledialog2/tst_qfiledialog2.cpp
Change-Id: I4656d8133da7ee9fcc84ad3f1c7950f924432d1e
This fixes errors linking against Qt when built as shared libraries and
with bitcode enabled (default on tvOS and watchOS).
Change-Id: I3eb3bb0b9615e0bc41e43ffae8645248dbf803c6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Mike Krus <mike.krus@kdab.com>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
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>
This allows overriding the INSTALL_ROOT with the Xcode generator.
Change-Id: Ifb894bdbf9764918f76428fb32d9af68914853f6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
This fixes the examples build on UIKit platforms in
examples/dbus/pingpong where there are two Xcode projects and the build
therefore cannot disambiguate between the two.
Change-Id: Ic8b808c1ddf3565bb9861a487eab6854ec177184
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
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>
- moved prf files to shared location (uikit, added to QMAKE_PLATFORM)
- prepare some formatting (unconditional blocks mostly) to add conditions later
- make device detection script more generic, passing filter strings
as a parameter and returning non-os specific variables
Change-Id: I61f2b77093304ff985bec9da04fda57ff296b16b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
