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 9daeb6fe9d
Amends 5574aa986b
Pick-to: 6.3 6.4
Fixes: QTBUG-102053
Change-Id: Ic4ea3b9e11c21ae535d6544cbed3670f9db44e72
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
If xcrun prints warnings or errors to stderr while determining the SDK
version, they become part of the SDK version string. This then leads to
a qmake error.
Intentionally ignore stderr so that it is not treated as part of the SDK
version.
Pick-to: 5.15 6.2 6.3
Fixes: QTBUG-102066
Change-Id: I023296b430aac1407c970412c5cf1010bd81589b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
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>
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>
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>
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>
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>
Change-Id: I0b35c32f3730dc15d868b10489abeda909bbe926
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
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>
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>
The sysrootification of QMAKE_INCDIR_OPENGL on macOS must happen only
once. Commit 49ef3773 addressed this but stored the sysrootified
QMAKE_INCDIR_OPENGL in qt_lib_gui_private.pri. For installer packages,
these paths are the paths of the build machine and most likely wrong
on the user's machine.
This reverts commit 4949ef377349ba4dae840c2d5caa36e2d516707baa and
restores the sysrootification in sdk.prf. The original include paths
are assigned to QMAKE_EXPORT_INCDIR_OPENGL and stored as
QMAKE_INCDIR_OPENGL in qt_lib_gui_private.pri.
Fixes: QTBUG-75374
Task-number: QTBUG-73736
Change-Id: I4c0f65866d60660c632363dba3adc7ea2e344bfc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The sysrootification of OpenGL include paths must be done only once: at
configure time. The resolved paths are stored since 521a8539 and must not be
resolved again.
Turn the makeSpec-type opengl library into a custom-type one, and do
the sysrootification in the handler function.
Fixes: QTBUG-73736
Change-Id: I2933144057d6f01d8bfc7bda2c2df56c57303459
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This reverts commit 37970d7b3e.
That commit broke the build on macOS, because the OpenGL headers aren't
resolved anymore at configure time.
Change-Id: Iec6ef009c9ea7e28b12eeca6b5eb06918bf49d98
Fixes: QTBUG-73827
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Since include paths are fully resolved, we must remove the code that prepends
the SDK path to the OpenGL include paths.
Change-Id: I80d74629c7fc989a89c3f1d95d6de43b4c1de17a
Fixes: QTBUG-73736
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Also catches some more variants of SDK mismatch, such as Xcode not
being installed at all, or the SDK missing.
Change-Id: I184aaa571ef0ea722ca64c54f665462dabc17533
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
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>
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>
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>
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>
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>
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>
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>
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>
the 'info' variable was re-used too early. make a new one 'infoargs'
instead.
Task-number: QTBUG-67286
Change-Id: I77881ecbfce338d653358c5e5edac84e1c0c7de3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
On Apple OSes, both compilers and linkers are given an absolute path.
For consistency, the same should be done with the C linkers.
The change is also a convenience to the MacPorts project,
which actively discourages ambiguous compiler names.
(https://trac.macports.org/wiki/UsingTheRightCompiler).
Change-Id: Ic1885aed825340696e9fde766788eebf51de3ff6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The PRODUCT_BUNDLE_IDENTIFIER property was not defined in the Xcode
project file and therefore the build would fail.
This fixes a regression introduced by 0749ba2c5e.
Task-number: QTBUG-65673
Change-Id: I8089b36d86588223ec34859af7388c99a3574d8b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
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>
Since Xcode 6.3, this must be set to NO because stripping on copy is no
longer fully supported due to the potential of input binaries being code
signed. In this case Xcode will simply ignore the strip step and issue
a warning since stripping would invalidate the code signature. This
change silences that annoying warning for release builds. Also, the
setting assignment is moved from being hardcoded in the generator, to
a QMAKE_MAC_XCODE_SETTINGS value.
Change-Id: If25511edddc12b7b0407e2992d80884b7d6437dc
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
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>
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>
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>
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>
