Currently, configure fails late with
Qt requires at least version 15 of Xcode, you're building against
version . Please upgrade.
Pick-to: 6.9
Change-Id: Ic4f44d37429ac9def785a50909a25b0bcb4b72a5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Starting with CMake 4.0, CMake doesn't initialize the
CMAKE_OSX_SYSROOT variable with any value when running on a macOS
host and no explicit CMAKE_OSX_SYSROOT or CMAKE_SYSTEM_NAME is set.
CMake expects the platform compiler wrapper /usr/bin/c++ to pass an
appropriate -isysroot flag to the underlying compiler, without CMake
explicitly setting one.
This mostly works, but the configure output will not show anymore the
active sysroot path.
Query the active path from xcrun, and display it in the configure
output.
Pick-to: 6.8 6.9
Task-number: QTBUG-135621
Change-Id: Ic9b9a43e25bb88bb83165dce52356c77ea8fffe1
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Introduce two new functions _qt_internal_get_apple_xcrun_output
and _qt_internal_get_apple_sdk_name, to allow reusing them in the
future.
Make sure to set the output variables to empty even
outside Apple platforms.
Show an error when xcrun is called when targeting a non-Apple
platform.
Pick-to: 6.8 6.9
Change-Id: Ic3895f74cfcac337bff069f8e6ec1517aec6c8d0
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The xcrun binary may be installed in a different location when cross
compiling to macOS using osxcross.
Change-Id: I47398e8da19c42e5e9d1b595673048c56662ea2e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We normally override the entrypoint to _qt_main_wrapper via the -e flag
to the linker, but if a Swift file is added to the Xcode project, Xcode
does some magic, building the app as a shared library, and wrapping it
with the Swift code into a custom executable. The -e flag will then be
a noop when linking our shared library.
To work around this we set the custom LD_ENTRY_POINT Xcode build setting,
which triggers Xcode to pass -e when linking the wrapper-executable.
This works in practice, but produces a warning on the console that the
entrypoint is not found, which has been reported as FB16519113.
Fixes: QTBUG-133577
Pick-to: 6.9 6.8
Change-Id: I9d8310b39ac5a4900693df55c2e5bfa346c0300a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The format of the Xcode preferences has changed, so we need to account
for the new format when looking up the default development team.
Pick-to: 6.9 6.8 6.5
Change-Id: Ib34c2e5245c13db4d81218a5a2460417e4fc6347
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
As well as the _qt_internal_apple_development_team_id_computed
property.
It's used for macOS as well, so use `apple` infix instead of `ios`.
Pick-to: 6.9 6.8 6.5
Change-Id: I7932166d094a14ac32cce95e6c9fcbfa44bb97b4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Starting with Qt 6.8+ we should error out if the minimum sdk / Xcode
version requirements are not met.
An opt out is added for cmake build tests, otherwise all the tests
that use private cmake api will fail to configure when run on older
Xcode or SDK versions in the CI.
We do this by checking for a new QT_INTERNAL_IS_CMAKE_BUILD_TEST
variable.
We do the check inside
_qt_internal_check_apple_sdk_and_xcode_versions
instead of passing
a QT_FORCE_WARN_APPLE_SDK_AND_XCODE_CHECK variable to the test
configuration, because not all cmake build tests use private api, so
this way the list of projects that get the opt out is more
constrained.
Pick-to: 6.8 6.9
Task-number: QTBUG-119490
Change-Id: I1284616c91341848a9cf6406fbf35750707d1227
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The full set is needed, on all platforms, so that we can use them
during documentation builds.
Pick-to: 6.8 6.5
Change-Id: Ie555094a8e365fada7e43da6899e312d774eadb2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake by default generates an Xcode project with an overridden
CONFIGURATION_BUILD_DIR Xcode attribute pointing to an absolute path
build dir.
Due to a bug in Xcode, that causes dSYMs not to be included in an
xcarchive after invoking the Xcode archiving task.
This can be worked around by re-setting the CONFIGURATION_BUILD_DIR
attribute to have the value "$(inherited)". That ensures that Xcode
places the dSYMs into an expected location, that can then be included
in an xcarchive.
Unfortunately overriding CONFIGURATION_BUILD_DIR breaks certain CMake
build path preconditions, which can result in broken behavior like
$<TARGET_FILE:app> genex evaluation not working, as well as ignoring
of the CMAKE_RUNTIME_OUTPUT_DIRECTORY property.
So modifying the CONFIGURATION_BUILD_DIR can only be done as an
opt-in, where the project developer knows the risks and can decide if
it will affect the project.
The project can opt into the risky fix by setting the
QT_USE_RISKY_DSYM_ARCHIVING_WORKAROUND cmake variable to ON before
creating any targets using qt_add_executable.
If Xcode fixes this bug in the future, we can make the variable a
no-op when we detect a new enough Xcode version.
Pick-to: 6.7 6.8
Task-number: QTBUG-126866
Change-Id: I37e8dee569fc45654f149219b8933769ed237fda
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
CMake by default uses the Release configuration for the Xcode archiving
task, providing no way to choose a different configuration. CMake also
sets the "generate debugging symbols" Xcode option aka the -g flag to
NO for the Release config, because it is not the RelWithDebInfo
config. This means that by default the archived project will never have
debugging symbols.
Change the GCC_GENERATE_DEBUGGING_SYMBOLS Xcode attribute to YES for
all the release configs (Release, MinSizeRel, RelWithDebInfo), as well
as the debug config. This matches the defaults of a project created
in Xcode directly and ensures debug symbols are generated for all
configs.
Another issue is that the Xcode project generated by CMake shows no
values for the debugging format option, which is controlled by the
DEBUG_INFORMATION_FORMAT attribute. In contrast a project created in
Xcode directly, sets the Debug config format to "dwarf" and the
Release config format to "dwarf-with-dsym".
This prevents inclusion of the dSYMs into the archive, because the
dSYM would not be created in the first place.
Override the DEBUG_INFORMATION_FORMAT per-config. The release configs
get the 'dwarf-with-dsym' variant, while the debug config will have
'dwarf'.
This matches the values of a new project created directly in Xcode.
Each of these assignments can be opted out by setting one of the
following variables:
- QT_NO_SET_XCODE_DEBUG_INFORMATION_FORMAT
- QT_NO_SET_XCODE_GCC_GENERATE_DEBUGGING_SYMBOLS
These changes improve the defaults for a CMake generated Xcode
project, but are not sufficient to ensure that dSYMs are included into
the archive created by the Xcode archiving task.
For that, the project also needs to set the CONFIGURATION_BUILD_DIR
attribute to '$(inherited)' to avoid a bug in Xcode, where it can't
copy dSYMs out of a non-inherited build dir into the archive.
Qt can't do that unconditionally, because it violates CMake's build
path preconditions, resulting in things like $<TARGET_FILE:app> genex
evaluation not working, as well as ignoring of the
CMAKE_RUNTIME_OUTPUT_DIRECTORY property.
A follow up change will provide an opt-in to do that, but only at the
project developer's own risk.
[ChangeLog][CMake] CMake-generated Xcode projects will now include
debugging symbols by default, regardless of configuration type, and
Release-like configurations will default to using dSYM bundles instead
of keeping the debug symbols in object files, to match Xcode project
defaults.
Pick-to: 6.7 6.8
Task-number: QTBUG-126866
Change-Id: Ie17b40e53ba22658a098f9a162c7bcfb1711c45b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The value of QT_I18N_TRANSLATED_LANGUAGES is reflected in generated
Info.plist files. We should do the same for QT_I18N_SOURCE_LANGUAGE.
Pick-to: 6.7 6.8
Fixes: QTBUG-126790
Change-Id: Id9d680a183047942585e00f5d8cf1ac3c2352c9f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Qt already runs on Vision Pro as "Designed for iPad", using Qt
for iOS. This change enables building Qt for visionOS directly,
which opens the door to visionOS specific APIs and use-cases
such as volumes and immersive spaces.
The platform removes some APIs we depend on, notably UIScreen,
so some code paths have been disabled or mocked to get something
up and running.
As our current window management approach on UIKit platforms
depends on UIWindow and UIScreen there is currently no way to
bring up QWindows. This will improve once we refactor our
window management to use window scenes.
To configure for visionOS, pass -platform macx-visionos-clang,
and optionally add -sdk xrsimulator to build for the simulator.
Change-Id: I4eda55fc3fd06e12d30a188928487cf68940ee07
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
...according to the Qt 6.7 CMake API review.
Pick-to: 6.7
Task-number: QTBUG-122396
Change-Id: I42012e346325ff05d63fa4dac44276eef15320fe
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Configuring a test as standalone would fail with the following error:
Invalid max SDK version: It should be a major version number,
without minor
This happened because _qt_internal_check_apple_sdk_and_xcode_versions
expects QT_SUPPORTED_MAX_MACOS_SDK_VERSION to be available, but it is
not yet set due to Qt6 package not being found yet.
Avoid the issue by exporting the version requirements into both
Qt6ConfigExtras.cmake and Qt6BuildInternalsConfigExtra.cmake.
Make sure to assign the variables only once.
Amends a29bff3d80219f54d0837b0e6e0577192011dea1
Amends a0bdd2195f24d8a7d880ba506afc16b41337218e
Pick-to: 6.6 6.7
Task-number: QTBUG-119490
Change-Id: Ic297eeaabf22c8c42ded1a766906f88fdb91fd3d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We need to warn only when using a major version that is the next one
after the 'max supported version'.
Add an assertion that the max sdk version specified in .cmake.conf
needs to be just the major sdk version, without a minor or patch
version component, otherwise the '+1' math expression will fail.
Pick-to: 6.6
Task-number: QTBUG-119490
Change-Id: Ib30abe7157c2ccbe0ad7a98e81fc241685a141a8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The minimum sdk / xcode version is a requirement, so if the minimum is
not met, we should generally error out.
Changing the behavior in the already released 6.6.x series is not nice
though.
Refactor the code to support both a warning-first and error-first
approach. Keep the warning-first behavior as-is in this change and pick
it to all relevant branches.
A follow up change will switch the default to the error-first approach
for as-of-yet unreleased Qt branches.
To support both approaches, there are now two variables to flip the
warnings into errors and vice-versa depending on which is the default
for a particular branch:
- QT_FORCE_FATAL_APPLE_SDK_AND_XCODE_CHECK
- QT_FORCE_WARN_APPLE_SDK_AND_XCODE_CHECK
The maximum SDK version check remains a warning, because building
against the newer SDK might still work, even if it isn't yet marked as
supported.
Amends a29bff3d80219f54d0837b0e6e0577192011dea1
Pick-to: 6.6
Task-number: QTBUG-119490
Change-Id: I92dedd69efc266dfc1c8cf15c93887be74fc99d8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It was an oversight.
Amends a29bff3d80219f54d0837b0e6e0577192011dea1
Pick-to: 6.6
Change-Id: I696d7a2650c336dc93df01245065bcbb61ca1d6b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The warnings are shown when configuring any Qt submodule or top-level.
The warnings are NOT shown when configuring a user project with CMake.
Opt out CMake cache variables can be set to silence any of the
warnings:
- QT_NO_APPLE_SDK_AND_XCODE_CHECK
- QT_NO_APPLE_SDK_MIN_VERSION_CHECK
- QT_NO_XCODE_MIN_VERSION_CHECK
- QT_NO_APPLE_SDK_MAX_VERSION_CHECK
The warnings can be upgraded into errors by configuring with
-DQT_FORCE_FATAL_APPLE_SDK_AND_XCODE_CHECK=ON
The platform version requirements that qtbase specifies in .cmake.conf
are saved in Qt6ConfigExtras.cmake so that they can be used when
configuring other non-qtbase submodules.
The code is added to the public CMake files, so that in the future we
don't need to move code around if we enable the checks for public
CMake projects as well.
The version extraction helpers were moved out of QtAutoDetectHelpers
into QtPublicAppleHelpers.
Task-number: QTBUG-119490
Change-Id: Ic840e1013aeb607bf23247a9cb43471dde802e9d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
As mentioned in comments, file(COPY causes rebuilding of the file every
time the project is re-configured, so, we replace it with configure_file
to avoid that.
Amend 1dcc14f2d08364411ff8f6dcd9e00277bcadef5d
Task-number: QTBUG-118191
Change-Id: I893b36fa26168f460f3ab1320a3194561c66e5df
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
On iOS, we can use system color variables to adjust the background color
of the LaunchScreen based on user's system preference. In addition, we
can remove the app name labels, since new Xcodes don't add it anymore.
Fixes: QTBUG-118191
Change-Id: I95fef6216f1373c749ea31ff4ed085435e8998f1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
[ChangeLog][CMake] Added variable QT_I18N_LANGUAGES to specify the
languages that are used for i18n in the project.
[ChangeLog][CMake] Added keyword I18N_LANGUAGES to
qt_standard_project_setup to conveniently set QT_I18N_LANGUAGES.
The call
qt_standard_project_setup(I18N_LANGUAGES hi ho)
sets the variable QT_I18N_LANGUAGES.
The target finalizers use this variable to set up CFBundleLocalizations
on Apple platforms.
qt_add_translations will be extended to read QT_I18N_LANGUAGES as well
to determine the names of .ts files if TS_FILES is not given.
Fixes: QTBUG-116716
Change-Id: I76f0753d10efb9c32947d9239e43382c9d85eb51
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
It's a bit excessive to warn every developer about this, especially if
they are using non-Xcode generators; besides, we are already generating
a bundle identifier if it is missing anyway.
Pick-to: 6.5 6.6
Change-Id: Ib11ad51a0e516e0ea61ad2f7bf499b846bc0b792
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If I'm not mistaken we would like to leave this to Xcode, if so, we can
use `$()` to make our intention more clear in the code.
Pick-to: 6.5 6.6
Change-Id: I3867f68f371a1cf1a5db5e639ec740f2546ccd75
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When using Ninja generator on macOS, we now do a bit of extra work to
make sure that bundle identifier is always set.
- In the case where no identifier was provided, the warning message has
been updated indicating that the user can set either of the
properties.
- If both `MACOSX_BUNDLE_GUI_IDENTIFIER` and
`XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER` were set but have
different values, a warning will be shown to encourage the user to set
only one of them.
- In addition `_qt_internal_get_ios_bundle_identifier_prefix` is renamed
to `_qt_internal_get_apple_bundle_identifier_prefix` to be more
platform specific.
Note:
In general, if Ninja is the generator, we set the value of
`MACOSX_BUNDLE_GUI_IDENTIFIER` and don't touch the
`XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER`. If Xcode is the
generator, we set the value of
`XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER`, and in addition, to
silence a Xcode warning, we set the `MACOSX_BUNDLE_GUI_IDENTIFIER`
to `${PRODUCT_BUNDLE_IDENTIFIER}`, ie., let Xcode figures it out if
needed.
[ChangeLog][CMake][macOS] When using Ninja generator, if neither
`XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER` nor
`MACOSX_BUNDLE_GUI_IDENTIFIER` is provided for a target, a bundle
identifier, i.e., `com.yourcompany.<teamid>.<target>` will be generated
and set as CFBundleIdentifier.
Pick-to: 6.5
Fixes: QTBUG-110889
Change-Id: Ie071085bbaf465afcb022b760423eb6b3c921f6d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For untranslated applications we set CFBundleAllowMixedLocalizations to
true, so that the application's locale will not be limited to the
development region "en".
But once we have a set of known translations, added by qt_add_translations,
we can turn these into CFBundleLocalizations, which lets macOS/iOS
choose a best match between what the app supports and what the user
preferences are.
[ChangeLog][Internationalization] Translations added via
qt_add_translations are now reflected as CFBundleLocalizations
entries in the application's Info.plist file on Apple platforms.
to disable this behavior, set QT_NO_SET_PLIST_LOCALIZATIONS.
Change-Id: I3f7ae1a1884eaf269038fa8ee49dbe6cac855706
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Allows us to modify this file in place, before CMake copies it into
the application bundle during its generator step.
Change-Id: I73325c66b5b8919f57dbaa1cc76a7edbc145609c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Unifies the approach between iOS and macOS. By copying the Info.plist
to the build directory, we also open up the possibility to modify it,
which we can't do when CMake does the copy during its generator step.
Change-Id: I59f9f69ac368166bb26d8a5c57bf4ea3f503d51b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QCore::applicationName() is influenced by what values we insert into
the Info.plist file of an application bundle.
We accidentally inserted tokens like ${PRODUCT_NAME} that are meant to
be expanded by xcodebuild, even when using a generator like Ninja.
This caused the applicationName() to report "${PRODUCT_NAME}".
Make sure to only call relevant finalizers for macOS applications
when using a generator other than Xcode.
Amends d5580aa7194b84306da52efb189cf126dbaee1f7
Pick-to: 6.4 6.4.0
Fixes: QTBUG-106652
Change-Id: Idbc9c84557a8f17b1302e6969f6eb317e3ef225d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
