Right now, image picker view is shown first (it does
not require access to photos, since it's essentially
Photos app getting access to photos ...). Then, we use
AssetsLibrary to get asset for an url (using ALAssetsLibrarie's
-assetForURL method). This may trigger a permission-related alert, asking to:
a. Select more photos or ...
b. Allow access to all photos or ...
c. Deny access.
Showing this alert _after_ picker has selected an image makes little sense
(and probably was never intended this way anyway). Instead, we now use
Photos.framework to check the authorization and, if needed, we request
an authorization (when the current status is 'Nondetermined'). If authorization
is 'Granted' as a result, we show picker view and proceed as normal/before.
Pick-to: 6.5
Task-number: QTBUG-109120
Change-Id: I0acfd7b0476346360d75a5e37f5845aaf2d6e3e0
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
To extract system proxies, the one we used previously, was not available
on iOS and thus we could not obtain system proxies there. Support is
limited - no such things, as SOCKS/FTP/etc. proxies, only PAC (auto
configuration), and HTTP/HTTPS. There are no keys to extract info
about HTTPS, so instead we'll use CFNetworkCopyProxiesForURL (
looks like this enables exclusion lists (which are hidden)
functionality and apparently from the system point of view HTTP/HTTPS
are the same.
Fixes: QTBUG-39869
Change-Id: I73af719a2e2b5cded706e6b3faa4b8eaa879352b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
<out_var>_private_header_dir and <out_var>_private_module_header_dir are
documented to point to "the specific framework version and framework
bundle version".
Pick-to: 6.5
Change-Id: I00053f106ec9be88f7892c842ca75549cfc54124
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
As of f68e2c92cc, and its follow up
changes, we can now link individual plugins statically, even if the
Qt build is generally a shared build.
This allows us to build Qt for iOS as shared libraries, while still
keeping the platform plugin as a static library, since this is
harder to port over to a shared library.
This gives the benefit of faster turnaround during development, as
well as binary compatibility promises for the main Qt libraries,
without having to go fully shared for all of Qt.
Static builds are still the default, due to the downsides of larger
application bundles and slower load times for shared builds.
For now the user has to manually tick the "Embed & Sign" check
box in Xcode for each Qt library, which is only available with
Xcode projects generated by the qmake Xcode generator.
Task-number: QTBUG-85974
Change-Id: Id2b7bd2823c8e7c79068dda95295b574ada8d7f2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@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>
syncqt.pl adds an extra dependency on perl when building Qt. Modern C++
provides the convenient cross-platform way to access a filesystem and
to use regular expressions, so we may replace the perl script with C++
application. The syncqt executable is built at configure time and
installed as QtCore tool. It's running at configure time to deliver the
required header files for IDE to build a consistent code model and at
the build time to keep tracking changes in header files and generate
the missing aliases without reconfiguring. 'syncqt' only parses header
files from a CMake build tree, so the resulting Qt installation only
contains interfacing headers that belong to the platform that Qt is
built for. 'sync.profile' files are not used as the 'source of truth'
for sync qt procedure anymore, all the necessary information is taken
from either CMake files at configure time or from the module header
files while parsing them.
syncqt.pl is still in place since it's required as fallback solution
for a smooth transition to the new syncqt implementation for all qt
repositories.
This patchset only enables the C++ based syncqt for 'qtbase'
repository.
From the performance perspective C++ version works faster then perl
script, also the configure time is reduced significally on subsequent
reconfigurations - up x2 times faster when re-configuring repository,
but it also takes time to compile the tool itself the first time.
Numbers for qtbase:
syncqt.pl syncqt.cpp
initial: 0m16,035s 0m20,413s
reconfig: 0m6,819s 0m3,725s
The syncing procedure can be run separately for each module using
<ModuleName>_sync_headers targets. The 'sync_headers' target can be
used to sync all the modules at once.
Task-number: QTBUG-87480
Task-number: QTBUG-103196
Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt_copy_framework_headers now can accept all the headers in one call.
This is useful for upcoming changes when it will accept generator
expressions as the input instead of actual files.
Change-Id: I110b6d9e6de976b2a7581902e051e38571716c5f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Use VERBATIM option to prepare the correct command line for the
add_custom_command. This especially sensitive when using build
directories with names containing special symbols, that cannot be
handled by shell correctly.
Change-Id: I51d7041cb806411135fd59bf6273c04a3c695443
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Set ${FWCryptoTokenKit} when the framework has been found.
This is useful for WIP card reader support in QtConnectivity.
Task-number: QTBUG-97946
Change-Id: I0e85e0fd2e0fc45fb3069bbdaa2d8b2c927a6c2d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The Qt bluetooth module uses ${FWCoreBluetooth} when building for iOS,
but that evaluated to empty.
Pick-to: 6.2
Change-Id: I93ff2c30697a912bed454087ae260fae9cc41b0f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In a -debug-and-release build, apps were placed under bin/Release
rather than just bin.
Apply the logic we use for tools for apps as well. Rename and move
the common functions into QtTargetHelpers.cmake.
Pick-to: 6.2
Fixes: QTBUG-95028
Change-Id: I5a9082ea50c9238c8fcf0c6dd099708fbc571bf8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
For Apple's frameworks it's possible to include header files using the
following assumption:
If the framework name is "MyFramework" then
'#include <MyFramework/frameworkheader.h>' will work without specifying
the include path explicitly. This is broken for internal modules since
they use the framework name with the 'Private' suffix.
This uses the module name instead of the target name as a framework
name.
Amends edbe0eb335
Task-number: QTBUG-87775
Change-Id: I0592a28d0768724b6e10ca81aa7cefb0a3699a5e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since the information about framework is performed in multiple places
it's quite hard to control its consistency. This moves the obtaining
of framework related information to the common function and adjusts
the use of the information across the repo.
Change-Id: I1f488d41dcea75a1e8c361926792a6b7c45e5a3f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In cmake, targets are used as an entity for modules. This causes a
number of problems when we want to manipulate a module as a separate
entity with properties associated with it.
The _qt_internal_module_interface_name target property is introduced to
represent the module entity. All modules write a name to this property,
which will subsequently expand into the module name matched with
the module name in qmake.
The 'qt_internal_module_info' function is responsible for providing the
correct values for the module properties used when working with a module
target.
Unlike qmake, for internal modules in cmake it is expected that the
Private suffix will be specified explicitly. In case the user wants to
have a different module name, an additional argument
MODULE_INTERFACE_NAME of the qt_internal_add_module function is
introduced.
This also changes the way how target dependencies are collected and
resolved. Since the 'Private' suffix no longer means an unique
identifier of the module 'Private' part, we look for the both Private
and non-Private package names when resolving dependencies.
TODO: This change doesn't affect the existing internal modules, so to
keep compatibility with the existing code the existing internal modules
create 'Private' aliases. The code that provides backward compatibility
must be removed once all internal modules will get the proper names.
Taks-number: QTBUG-87775
Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The CoreMotion is required by the QtSensor module.
Task-number: QTBUG-92502
Change-Id: I7f1853131aa96b2cb052862d5bf492df5ec18150
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
All system frameworks use 'A' instead of the major version of the
framework, and Xcode's code signing assumes that the framework version
is 'A' when signing embedded frameworks (FB7323980), so leave the
version 'A'. This is also what Apple recommends.
Change-Id: Idbf2e30e156c3e869da8f75731e568524d9407e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Using find_library() to find an Xcode framework will end up embedding
the absolute path of the framework into INTERFACE_LINK_LIBRARIES.
A different machine might not have the SDK installed in the same
location, which will cause build failures. This happens in our CI
because Xcode is installed to /Applications/Xcode11.app.
To fix this, replace all system framework paths with
'-framework Foo' flags instead.
We already do this for OpenGL and OpenGL ES.
In the future we might want to convert these into full standalone
FindFoo scripts that expose proper targets.
Fixes: QTBUG-86299
Task-number: QTBUG-86422
Task-number: QTBUG-85240
Change-Id: I22b2b2d1d9e92108098d3974105e3758978cd8e2
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
QtBuild.cmake is huge. Split it.
Move module, plugin, tools, executables and test related functions out
of QtBuild.cmake into separate files.
Do the same for many other things too.
An additional requirement is that all the new Helpers files only
define functions and macros.
No global variable definitions are allowed, nor execution of commands
with side effects.
Some notes:
qt_install_qml_files is removed because it's dead code.
Some functions still need to be figured out, because they are
interspersed and depend on various global state assignments.
Task-number: QTBUG-86035
Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
