Play Store now accept only app with target
SDK version set to 31 or above
Change-Id: I7f7fb677798c3f2d3ce327226ac13a69f0bab442
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Qt requires them and will fail to build if it isn't met, so we don't
need to check for its support. These were public CMake and qmake
features, so to keep compatibility with existing they're hardcoded now
(only done for the C++ editions and for qmake only, as that's what Qt 5
did).
Change-Id: I7f354474adce419ca6c2fffd174814724f45f90b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Recent Emscripten 3.1.27 reduces the stack size to 64KB,
which is way to small for Qt-based applications.
Restore the previous stack size (5 MB) by setting STACK_SIZE.
Change-Id: I6c25e31b32dc1d551fa423655fcef4891830bcd1
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
The qtPlatformTargetSuffix() function is used in various places to
determine the suffix of targets based on the config, which for macOS
will result in a _debug suffix in debug mode.
This becomes tricky when one project built in debug mode tries to depend
on the libraries/plugins of another project (Qt) built in release, as
the qtPlatformTargetSuffix() function uses the current CONFIG as input,
which may be different than the QT_CONFIG (or CONFIG of whatever project
is being depended on).
For libraries this was fixed in 50e664835b
by iterating all known library paths, and trying the CONFIG suffix before
falling back to release version.
For plugins this was never solved, which becomes an issue when linking
to static plugins, either in a fully static build of Qt, or when some
of the plugins are static (permission plugins e.g.).
In this situation, the user project has to have the same configuration
as Qt was built with, to avoid errors like:
error: no such file or directory: '~/6.x-static/qtbase/plugins/platforms/libqcocoa_debug.a'
To work around this, we assume that a plugin installed into the Qt
tree has the same build configuration as Qt itself, then then use
QT_CONFIG as the determining factor when linking to the plugin.
This still ties the build config of the plugin to the config of Qt,
but relaxes the relationship to the application, allowing it to be
built in either debug or release, which is an improvement to the
current state.
Pick-to: 6.5 6.5.0
Task-number: QTBUG-110356
Change-Id: Icee67fc01313a6c6f34178a6345ccae1b57429d7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Repeating the body of the reported bug, "Building Qt modules with qmake
is unsupported in Qt6 and since 6.5's switch to syncqt.cpp broken."
[ChangeLog][qmake] Support for building Qt modules with qmake was
removed.
Pick-to: 6.5
Fixes: QTBUG-110134
Change-Id: Iee5aa5c85f7106bce742df448ec502e6cc039454
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Few tweaks:
- Remove extra closing parenthesis
- Use absolute paths as the exists() checks & other plist path
uses are relative to the permissions.prf location
- Use the plist path with PlistBuddy instead of the variable
from .pro file
Pick-to: 6.5
Change-Id: I27c7f1e7044a55ff7fbd78ef1dd79c92b17e8018
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This reverts commit d7e8d5bb1b.
Reason for revert: Found a working solution for the issue.
Change-Id: Ia720cc63ece9dfb1a24067cdd9c3d79d4edbe3be
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Right now, "multi abi builds" of android projects works only if the
android-build installation doesn't use custom install dirs
(INSTALL_PREFIX, INSTALL_BINDIR...)
At the same time, it fixes QTBUG-106533. The patches are the same as the
ones in that bugreport.
Add new items to android-*-deployment-settings.json:
qtDataDirectory
qtLibsDirectory
qtLibExecsDirectory
qtPluginsDirectory
qtQmlDirectory
Update androiddeployqt to be able to get files from their install location
BTW (fixes QTBUG-106533):
Install src/android/templates into INSTALL_DATADIR
Install src/3rdparty/gradle into INSTALL_DATADIR
Install src/android/java files into INSTALL_DATADIR
Install all jars into INSTALL_DATADIR
Add missing path to target_qt.conf
Update target_qt.conf to have all path. Otherwise qmake wouldn't have
the path when installing the android-build with custom install dirs
like INSTALL_LIBDIR & friends
Add support for a new cmake variable that can be set at build time of the
android projects: QT_ANDROID_PATH_CMAKE_DIR_${abi} (Name chosen as
brother of QT_HOST_PATH_CMAKE_DIR)
Pick-to: 6.5
Fixes: QTBUG-106533
Fixes: QTBUG-107207
Change-Id: Ia3751362ab1b5f877ecafbe02f263feac167119c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Otherwise we might conclude that we found a usage description when
PlistBuddy outputs "Error Reading File: /tmp/Info.plist" to stdout.
For CMake this is not an issue as we pipe stderr to a separate variable,
that contains "Cannot parse a NULL or zero-length data" in this case.
Fixes: QTBUG-109967
Pick-to: 6.5
Change-Id: I9d819b6de405b88bb7d1d75c22b6f5187f26e553
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We are seeing ~200 000 compiler warnings coming from Integrity compiler
not seen on other compilers. Suppress these as a hotfix reduce the
load on CI.
Change-Id: I9636104f07e81f9f5cf39b7fac2ac34ec2456db5
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Qt 6.5 will require emscripten 3.1.25. This is not the
most recent version (3.1.27 at the time of writing),
however .26 and .27 make changes to stack layout and size
which require further investigation.
Change-Id: Ibe285ef160d450d6b2c63a7fb71d3561b0032e37
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
This adds a new platform named wasm-emscripten-64
which sets the build and link argument -MEMORY64
You may see this warning, please ignore at your own discretion:
em++: warning: -sMEMORY64 is still experimental. Many features may not work.
[-Wexperimental]
Fixes: QTBUG-104891
Change-Id: I8d3150d239ba72dbef5c2352e0171d6cfbe51b59
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The values should come from android-clang mkspecs. The hardcoded
values don't work correctly with recent Android NDKs.
Pick-to: 6.4 6.2 5.15
Fixes: QTBUG-108662
Change-Id: Ie153a50ee0c49bd4f0704b588a4e2c87a05c1063
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
macOS Catalina (10.15) has reached its end-of-life, and is no longer
supported with bug fixes or security updates by Apple.
Change-Id: I65d0f572785bc77a563be925cf64823c20b9e015
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
When submitting applications to the iOS and macOS AppStore the
application goes through static analysis, which will trigger on
uses of various privacy protected APIs, unless the application
has a corresponding usage description for the permission in the
Info.plist file. This applies even if the application never
requests the given permission, but just links to a Qt library
that has the offending symbols or library dependencies.
To ensure that the application does not have to add usage
descriptions to their Info.plist for permissions they never
plan to use we split up the various permission implementations
into small static libraries that register with the Qt plugin
mechanism as permission backends. We can then inspect the
application's Info.plist at configure time and only add the
relevant static permission libraries.
Furthermore, since some permissions can be checked without any
usage description, we allow the implementation to be split up
into two separate translation units. By putting the request in
its own translation unit we can selectively include it during
linking by telling the linker to look for a special symbol.
This is useful for libraries such as Qt Multimedia who would
like to check the current permission status, but without
needing to request any permission of its own.
Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Change-Id: Ic2a43e1a0c45a91df6101020639f473ffd9454cc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
If Qml module is not found it doesn't make sense to run any
functionality that is related to Qml inside androiddeployqt. Add the
deployment setting option that indicates this explicitly and set it
to true when Qml module is not found by CMake or by qmake.
Task-number: QTBUG-106939
Pick-to: 6.4 6.2
Change-Id: I1e6cffbdd230007feffe7448617097c10238a6c9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
We currently don't have any machinery for qmake or CMake to map
translations declared via TRANSLATIONS += or qt_add_translations
to the Info.plist CFBundleLocalizations key.
This results in macOS and iOS falling back to the development region,
CFBundleDevelopmentRegion, as the only supported localization of the
app, which is in most cases set to 'en'.
Unfortunately this doesn't work well with the behavior of iOS 11+
and macOS 10.13+ where the OS will set the locale of the app to
the best match between the app's supported localizations and the
user's preferred language.
https://developer.apple.com/library/archive/qa/qa1828/
Since we only support a single localization, the development region,
the locale always ends up as 'en_<REGION>', which after QTBUG-104930
is also reflected in the QLocale's uiLanguages(), resulting in the
QTranslator machinery always picking English translation for the app.
As long as we don't explicitly declare CFBundleLocalizations we need
to opt out of the system's behavior of finding the best match between
the app's declared localizations and the user's preferences, which we
can do via the CFBundleAllowMixedLocalizations key.
Fixes: QTBUG-63324
Pick-to: 6.4
Change-Id: If7586d342148cbbb1d2a152cef039aad4448b13c
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This is consistent with what $(DEVELOPMENT_LANGUAGE) reports, as well as
the Apple Locales Programming Guide which states that "Locale names such
as “English”, “French”, and “Japanese” are deprecated in OS X and are
supported solely for backward compatibility."
Pick-to: 6.4
Change-Id: I99779d678ef9d4ea90249572f2f977e9b4df6c62
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Aligns with what our CMake Info.plist has for macOS, what we do for
both qmake and CMake on iOS, and what Xcode generates for new projects.
The value is hard-coded to English instead of using $(DEVELOPMENT_LANGUAGE)
as the file will be used by both the Makefile and Xcode generator, and
only the latter does variable replacements for $(FOO).
Task-number: QTBUG-63324
Pick-to: 6.4
Change-Id: I87e1cb14b14a9746b3603016c2ac69c252d37ff6
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This spams the console with "writeStackCookie"/"checkStackCookie"
messages, which makes finding relevant debug output harder.
Pick-to: 6.4
Change-Id: I352b633f02f9ecc1333d1d91f5ffc21a4a937e53
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
I noticed that the QtCore version file had several entries for
13QObjectPrivate, which turns out to be for all the nested structs
inside. That's not harmful for QObjectPrivate, since that is itself a
private, but would be a problem for a nested struct of a public class.
I'm sure those exist.
Pick-to: 6.4
Change-Id: Ic6547f8247454b47baa8fffd170ea79360aaa615
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Unexported structs do mark private API too. This change necessitated fixing
the negative-lookahead, because otherwise we'd match a line like:
class QVariant;
With $1 = "QVarian" and the "t" stood for the negative lookahead.
Pick-to: 6.4
Change-Id: Ic6547f8247454b47baa8fffd170bba2c68c29dbc
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Unify the settings for single-threaded and multi-threaded builds;
Qt now always enables heap growth by default.
This means we don't have to reserve a large (1GB) fixed memory
size, but can instead set the smaller (50 MB) initial memory size,
like the single-threaded build does.
Enabling threads + memory growth can potentially cause
a performance regression when accessing heap memory from
JavaScript (https://github.com/WebAssembly/design/issues/1271).
We leave it for the application to decide if this applies,
and if the switch to fixed memory should be made.
Change-Id: I96988b072506456685086e55aca4007a146bd70f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
In case they get erroneously extracted. For example, in Core5Compat,
QTextCodec appears in the _p.h as a full class if !QT_CONFIG(textcodec)
(I don't know what that is for, but it's there).
Pick-to: 6.4
Change-Id: Ic6547f8247454b47baa8fffd170eb1d0f7e6d0f9
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This fixes some threading bugs
Pick-to: 6.4
Change-Id: I1a96dcc54d8338de09b551d52a166d073e85d752
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Remove keys that are not needed: CFBundleSignature and
LSRequiresIPhoneOS.
Add CFBundleDevelopmentRegion, which is added by default in new Xcode
projects.
Pick-to: 6.4
Task-number: QTBUG-95838
Change-Id: I090c14561bc812ec255f55001b658d2dc60e11f3
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Emscripten's option for enabling asyncify (-sASYNCIFY) is a link-time
option, which means there is no requirement to have a separate asyncify
build, at least for static builds.
Replace the current QT_HAVE_EMSCRIPTEN_ASYNCIFY compile-time option
with a run-time option which checks if the asyncify API is available.
Keep support for configuring with "-device-option QT_EMSCRIPTEN_ASYNCIFY=1"
for backwards compatibility and for the use case where want asyncify
support to be on by default for a given Qt build.
Enable asyncify for the asyncify_exec example.
Pick-to: 6.4
Change-Id: I301fd7e2d3c0367532c886f4e34b23e1093646ad
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
They should contain the executable suffix .exe when
androiddeployqt is run on Windows, because androiddeployqt does not
add the suffix itself when the tool paths read from the json file.
Amends 4fc14b1933
Amends 176136ce60
Pick-to: 6.4
Fixes: QTBUG-105133
Fixes: QTCREATORBUG-27868
Change-Id: I8c5bac2fa6c82d122f8a70c5ff2a561298327a34
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
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>
Developers can add to Emscripten's EXPORT_RUNTIME_METHODS
by defining their own using:
QT_WASM_EXTRA_EXPORTED_METHODS
Which will add on to Qt's default exported runtime methods
of UTF16ToString,stringToUTF16
for cmake:
set_target_properties(<target> PROPERTIES QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap")
or
set(QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap")
for qmake:
QT_WASM_EXTRA_EXPORTED_METHODS = ccall,cwrap
Done-with: Mikolaj Boc
Fixes: QTBUG-104882
Pick-to: 6.4
Change-Id: I9678bdb7b077aaa8527057212ea4e161c0be0b60
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This amends commit fc2e40e88d.
For Qt plugins, we do not add 'dlltarget' to INSTALLS but only 'target'.
In this case we must add the .dll.debug file to 'target' like we did
before fc2e40e88d.
Fixes: QTBUG-105374
Pick-to: 5.15 6.2 6.3 6.4
Change-Id: If495548dfca55d02e1c5884e03e281e27ee07ccd
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
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>
It's perfectly possible to create static plugins in an otherwise shared
Qt build, but the logic to import these plugins into applications was
assuming a fully static Qt build. We now handle this more granularly.
Change-Id: Iacfa72f04c7918613b50ca87cf123e7f4c0841d5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Sanitizing the contents of the QTPLUGIN variable, and adding default
plugins from the available modules, should be a separate step before
the resulting QTPLUGIN is iterated and processed by for example linking
to each plugin, generating an import file, and adding module dependencies.
This makes it easier to add logic to the processing step later on.
Change-Id: I00e826c7fe87b29cf2e6bf4e1901c4d1482a20e6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And take the opportunity to remove the "m" in the qmake feature name and
.prf file.
Pick-to: 6.4
Change-Id: I36b24183fbd041179f2ffffd170224ab75cdd968
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Clang has the option, but spells it differently.
Fixes: QTBUG-105002
Pick-to: 6.4
Change-Id: I36b24183fbd041179f2ffffd170217e82ff6d14d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The existing mkspecs for Raspberry Pi 4 (devices/linux-rasp-pi4-v3d-g++) was intended to compile Qt application for the 32-bit version of Raspberry Pi, thus it used compiler flags that are incompatible when compiling Qt application for the ARM 64-bit architecture. According to ARM compiler documentation, -mfpu flag is rejected by AArch64 state while its alternative, -mcpu, has to be avoided when -march flag is already defined. -mfloat-abi flag is not valid with AArch64 targets.
To support both 64-bit and 32-bit architectures, I proposed to add this new mkspecs.
See:
https://developer.arm.com/documentation/101754/0618/armclang-Reference/armclang-Command-line-Options/-mfpuhttps://developer.arm.com/documentation/101754/0618/armclang-Reference/armclang-Command-line-Options/-mfloat-abi
Pick-to: 6.3 6.4
Change-Id: I36574875e798281688601edd0f166922592d9830
Reviewed-by: Tatiana Borisova <tatiana.borisova@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
