According to latest clang source code (llvm-14.0.3) non-fragile ABI
is default for everything but i386 which means we can stop passing the
-fobjc-nonfragile-abi option.
See
https://github.com/llvm/llvm-project/blob/llvmorg-14.0.3/clang/lib/Driver/ToolChains/Darwin.h#L245
This gets rid of the following warning when building a qmake project
for iOS, while targeting the iOS simulator:
clang: warning: argument unused during compilation:
'-fobjc-nonfragile-abi' [-Wunused-command-line-argument
It only happens for the simulator case because Xcode adds the
-fobjc-abi-version=2 option, thus the qmake one gets ignored.
As a drive-by also remove the usage of the -fobjc-legacy-dispatch
option. According to clang sources it should be implicitly used
on iOS.
See
https://github.com/llvm/llvm-project/blob/llvmorg-14.0.3/clang/include/clang/Basic/ObjCRuntime.h#L100
Amends d788f636691df5cae59d44a3828a0ddd58c343d0
Pick-to: 6.2 6.3
Fixes: QTBUG-103001
Change-Id: I06f8e46e40a1f04c5bbc4f177afa035e525dfed6
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QWidget::metric is used to calculate the size of the menu, but it
only respects a sceen from a Window handle, so we need to make
sure such a thing is created.
Task-number: QTBUG-103309
Pick-to: 6.2 6.3
Change-Id: Ie73e362cdcb3b59f46ad51c4901fdbeda7258baa
Reviewed-by: Morten Kristensen <me@mortens.dev>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Amends 2a893db480, which changed the
#ifdef'ery but didn't actually enable the building of the test on
Android.
Task-number: QTBUG-87414
Pick-to: 6.3 6.2
Change-Id: Id944dd3023da40ecbf4b8a324784409a63f94aec
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Add a template function that allows us to get the method signature
string from a free function, which are used as native callbacks methods
from Java.
Provide a macro that defines a signature object, and a JNINativeMethod
object based on it, in an internal namespace so that we don't pollute
the namespace with generated names.
Add another macro to get the generated JNINativeMethod object based on
the free function name.
Lastly, add overloads to QJniEnvironment::registerNativeMethods that
take a std::initializer_list of JNINativeMethods.
We can now declare a free function to be a JNI native method:
static bool callbackFromJava(JNIEnv *e, jobject /*thiz*/, jstring p1)
{
// ...
}
Q_JNI_DECLARE_NATIVE_METHOD(callbackFromJava);
and register it with the JNI environment like this:
QJniEnvironment jni;
jni.registerNativeMethods(clazz, {
Q_JNI_NATIVE_METHOD(callbackFromJava)
});
removing a significant amount of boiler plate code.
Change-Id: Ie4007b24125879fed3dae1f4d232b4aa95999b44
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
When replacing a widget in a hidden splitter, then we only need to keep
the new widget hidden if the previous widget was hidden.
If the new widget is not explicitly hidden, and the splitter is already
visible, then we need to explicitly show the new widget.
Augment test case; the existing test cases already cover swapping out a
collapsed or hidden widget.
Fixes: QTBUG-102134
Pick-to: 6.3 6.2
Change-Id: I9b60711a5c1cab79777ce4183783114a16ac3394
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Tested with MSVC 2022 locally and this change doesn't
break the bootstrapped builds.
Change-Id: Ieeb9a77035d889b9c1ed0c0c3488ac8802879282
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Prepare to replace a large pile of #if-ery-laden tangled mess from the
implementation of V4 Date by implementing a cleaned-up version of one
of its offset calculations and using a recently refactored API of QDTP
to implement the other.
Task-number: QTBUG-95993
Change-Id: I469f67fb384543abeece9ce8b14bb294c8613033
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When combining text alignment flags, it no longer works since the
metatype for example QVariant(Qt::AlignRight | Qt::AlignVCenter) is
uint, not int.
Fixes: QTBUG-103576
Pick-to: 6.2 6.3
Change-Id: If0291b99606787081c4bc26fd00431f8a17a61a2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QMetaType can register a converter from a smart pointer class to
QObject *. The code tries to do so even if the smart pointer is
actually holding a pointer to a _const_ QObject
(e.g. shared_ptr<const QObject>), causing a compile error:
../src/qt5/qtbase/build/include/QtCore/../../../src/corelib/kernel/qmetatype.h:1208:32: error: invalid conversion from ‘const QObject*’ to ‘QObject*’ [-fpermissive]
1208 | return p.operator->();
| ~~~~~~~~~~~~^~
| |
| const QObject*
Disable the conversion if indeed the source is const qualified.
Change-Id: I9e9bc5992f74131e5cfd6ece9b83d4f26d370e92
Fixes: QTBUG-103741
Pick-to: 6.2 6.3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
If a previous handler was already installed, ensure it is called,
because there may be a reason why it was there. For example, the Android
ART adds a signal action to every fatal signal for logging purposes. We
do that by restoring the signal handler we had and re-raising the
signal.
If our handler was overridden by something else, then that handler was
already called, but will get uninstalled after our code runs. It won't
be a problem, because the application is exiting anyway.
[ChangeLog][QtTest][Behavior Change] On Unix, the QtTest code to
handle Unix/POSIX fatal signals will now call back to the original
handler that was installed, if there was one. This allows logging
frameworks (such as Android ART's), for example, to log the crash too.
Additionally, if there was no handler, the application should exit with
the correct signal instead of SIGABRT.
Fixes: QTBUG-97652
Pick-to: 6.3
Change-Id: Ifc4fca159b490d8d0b614d736e46caefcb903a4c
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
And only restore those signals, instead of iterating over all possible
signals, instead of attempting to restore to SIG_DFL. Also, as a
consequence, we will install our handler even if there was already a
handler installed for the signal.
Pick-to: 6.3
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eb756685f4e8b8
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
And remove the unreachable code after std::abort() that was meant to
mimic that in INTEGRITY. The next commit will fix this properly.
Pick-to: 6.3
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eb772018add694
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The #if around the function declaration was ugly.
Pick-to: 6.3
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eb7540f5da080f
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We get stack space reserved instead of using the heap.
Pick-to: 6.3
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eb73fff0174150
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
They're very different, so there's no point in having them even in the
same class body. I've renamed the Windows one because Windows does not
report crashes via signals anyway. If you have an IDE that can scan both
branches of the #if, it will help you find the Windows-specific code
too.
Pick-to: 6.3
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eb73ba196cfb74
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The Qt environment handling functions lock a mutex. That's a big no-no
in signal handlers.
[ChangeLog][QtTest][Behavior Change] QtTest will now check the value of
the environment variable QTEST_PAUSE_ON_CRASH in QTest::qRun(), so if a
test wants to modify this variable, it must do so from the main() or
initMain() functions, not in the test itself (including initTestCase()).
Pick-to: 6.3
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eb78867cd8f54e
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This should work so long as there's no async-unsafe pthread_atfork()-
registered callback.
Pick-to: 6.3
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eb72e4e313bc19
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The QKeySequencePrivate default constructor wasn't constexpr, so
shared_empty was not constinit'able. To make the constructor
constexpr in C++17 as well as C++20, needed to replace the fill_n()
on the key member with Uniform Initialization.
Found by attempting to apply C++20 constinit to its definition.
Pick-to: 6.3 6.2
Change-Id: I2941e96348eb969029da2f0f7231079967bba996
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Constexpr acts as a static assertion that these objects don't incur
runtime initialization overhead.
Also mark some functions constexpr that can be.
As a drive-by, rename relational operator arguments to the usual lhs,
rhs.
Task-number: QTBUG-100485
Change-Id: I73d2595ccb123f28459edf79ae8dc208f26cc364
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Replace implicit conversions from QAtomicPointer<T> → T* with the
equivalent, but explicit, loadAcquire().
This is in preparation of deprecating the implicit QAtomic<T> ↔ T
conversions.
Change-Id: I6c8476a705c3996ef724dd63b58d9526d1a39af7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The implicit conversion operator from QAtomicPointer<T> → T* performs
a loadAcquire().
In the cases of this patch, we're only comparing pointer values to
check whether QObject thread affinities are compatible, so relaxed
loads suffice.
Pick-to: 6.3
Change-Id: If19124778b4770d86baeaeb3c91214e47881b288
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
The same information is written out a few lines above. Amends
ff153d9874
Change-Id: I168051250b79549f1ea4998e1fe00b8c63602432
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Keep the old behavior from 6.0 to 6.2.
Fixes: QTBUG-102637
Pick-to: 6.3
Change-Id: I2e596c7d5161a3dc7a8493358e272a481aee5308
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
It's possible to have multiple X screens, and a primary monitor on
each X screen. We should only use one on primary X screen as
primary QScreen.
The reference of QXcbScreen pointer should be used correctly.
Fixes: QTBUG-102758
Pick-to: 6.3
Change-Id: I1eafd509c8c109606967a4abe9ad7e9d8c0dd464
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QtConcurrent map- and filter-reduce functions take an initial value,
which can be of any type that is convertable to the result type. The
side-effect of this is that the enum values passed as ReduceOptions can
be treated as an initial value (if they are convertable to the result
type) which will result into a wrong overload call. To avoid this, added
additional check to make sure that the initial value type doesn't match
with ReduceOption enum.
Note that this required including the qtconcurrentreducekernel.h header
in qtconcurrentfunctionwrappers.h (which contains compiler checks for
QtConcurrent) for accessing ReduceOption enum, so I had to get rid of
qtconcurrentfunctionwrappers.h include from qtconcurrentreducekernel.h
to avoid circular header includes. This, in turn, required moving the
QtPrivate::SequenceHolder helper type to qtconcurrentreducekernel.h,
which didn't belong to qtconcurrentfunctionwrappers.h anyway.
Pick-to: 6.3 6.2
Fixes: QTBUG-102999
Change-Id: Ieaa8ef2e4bd82ce2ada2e0af9a47b87b51d59e87
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The SIP configuration is not available through the NVRAM in all cases,
so we try to get it via the private syscall first, if we can, and then
skip the warning if we don't find it in NVRAM.
Pick-to: 6.2 6.3
Change-Id: I0866d06c329a3ac70bb1f23732d10aab13a4f9c1
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This reverts commit 1e938c348b
and bb2f4d08d9.
bb2f4d08d9 causes the crash, but 1e938c348b amends it, so
this reverts both. When the cause of the crash has been determined
and mitigated, the patches can be recreated.
Fixes: QTBUG-103719
Change-Id: Ifc36b3771a96f6c85387a5306a0402d4c508d006
Reviewed-by: David Faure <david.faure@kdab.com>
What remains is all tangled together, but is now at least decoupled
from the rest of qdatetime.cpp, so moving it out makes that file
easier to read.
Task-number: QTBUG-95993
Change-Id: I3fba15aea59b3c8b4cbc6bf1cb03de96d68db0ce
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... in new qlocaltime* files, now that it's decoupled enough from the
internals of QDateTime for this to be possible. Part of the
consolidation of time_t code in one place.
Move assorted constants from qdatetime.cpp to a private namespace in
qdatetimeprivate_p.h to be shared between q*time.cpp hereafter (fixing
an out of date comment in the process - julianDayFromDate() is long
gone).
Task-number: QTBUG-95993
Change-Id: I03d97e959118041f9d86b8bb2e738599bc0b17e1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since qt_mktime() took QDate and QTime in/out parameters, its callers
had to convert the milliseconds they had to that form and back again
after. Since it combined optional look-up of zone abbreviation with
determination of offset and DST-ness (both ignore when the
abbreviation was asked for) it made sense to split it in two.
Each takes the millis and whatever knowledge we have of DST. One
returns tha abbreviation; the other returns a QDTP::ZoneState for the
caller that'll be returning that. Outside the system zone, when we
have to fall back to a kludge, their callers can now use the Julian
Day number change for its fake date to directly adjust the millis
there and back (effectively inlining former conversions to-and-from
date and time representation, but optimising out some of the work).
Change-Id: I7aa4583171f77fc0f4aa80c8f564e76995ca69d2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Now that I've disposed of the callers that were or might be passing
null pointers for the out-parameters, getDateTime() can inline its
computation and the two other callers can use msecsTo{Date,Time} until
I eliminate the need for that.
Change-Id: Ia9169779cf03189fc7fd5271044d1ec90089fa03
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Aside from one client that wanted the zone abbreviation for a given
local time (and could supply a DST-ness hint), the callers actually
want to know the offset from UTC, DST-ness and any correction needed
to the local time to dig it out of a spring-forward. Mediating all of
that via a QDate, a QTime and a returned UTC seconds since the epoch
was not making our lives any easier.
Split the local-time function into one to get the abbreviation and
another to determine the data we actually need. The zone version only
needs the latter. Two functions with hairy signatures replete with
in/out parameters are replaced with three, with no in/out
parameters. Adapt all callers of the old functions to use the new,
simplifying them in the process. Inline some conversions between
date+time and msecs in the process.
Change-Id: Ice60b615121a99111ed882734785fa3c777e191c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Break out the part that calls the appropriate platform variant, so
that the logic of what we do with the result of that isn't tangled up
with the #if-ery. Rework the remainder to return a struct type that
packages the data we need, to get rid of the three out-parameter
pointers.
Change-Id: Ibba6f8de0954fab3fddf9e95adc18ef85e45ff72
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Formerly, setMSecsSinceEpoch() passed a QDate and a QTime to
epochMSecsToLocalTime() as in/out parameters, then obtained what it
actually wants, a count of milliseconds, from their modified values
and computed an offset from that. Pass the epoch milliseconds from
which the QDate and QTime were derived in place of them and return the
local milliseconds, offset and DST status back in a structure, rather
than via pointer parameters.
This prepares the way for pushing one step further, back into
qt_localtime(), so that we can simply get the count of milliseconds,
along with DST flag and offset from UTC, without going via QDate and
QTime (except in the kludge that copes with times outside the time_t
range; and even that can be short-cut somewhat).
Change-Id: I37ebb1efb355e81e1a116d03cbd52f9bb4a1f114
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's documented to return true "if both the date and the time are
valid and they are valid in the current Qt::TimeSpec" but it was using
testAnyFlag() so would have returned true if any one of the three
conditions was met, rather than only if all three are met.
Change-Id: I91746224009d820abaffb541d8f6d6b13142849b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The formerly cumbersome arithmetic, to adjust for division rounding
towards zero rather than down, is so much simpler this way. Break out
the conversion for only date and for only time, for the sake of (for
now) two callers that only need one; and inline QRoundingDown::qMod()
to save repeating the qDiv() call. Include the mapping from millis to
raw Julian Day as a separate function, as I'll be using it shortly.
Change-Id: I0ee74ea68421a347ed618fa34142bd034844351e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Apple ties iOS application bundle identifiers to Apple accounts.
When building against the device SDK, the bundle identifier must be
unique, so that Xcode can register the id with the used developer
account and create an appropriate provisioning profile for the used
device.
If it's not unique (was previously used on a machine with a different
developer account), in the best case you get an error explaining that.
In the worst case you get an error about automatic signing not being
enabled (at least on the command line).
When building an Xcode project for the first time on a fresh machine,
the organization bundle identifier prefix might not be set.
Opening a Qt example project on such a machine might result in
generating the same bundle identifier, leading to the error described
above.
Warn project builders that they should either specify a prefix or an
entire unique identifier.
To ensure building still works in such a case, try to hash the team
id if it is present and add it as an infix to the auto-generated
bundle identifier.
Note that simulator builds are not affected by id uniqueness because
apps deployed to the simulator do not require a provisioning profile
from Apple.
Amends 4d838dae5a
[ChangeLog][iOS][CMake] The build system tries to create a unique
bundle identifier based on the team id if no organization prefix can
be retrieved from Xcode preferences.
Pick-to: 6.2 6.3
Task-number: QTBUG-95838
Change-Id: I6ad10076751acf43064330a6e53d6c4e973ec362
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Developers could use two different CMake properties / variables to
specify the bundle identifier of an application. One would be written
into the Info.plist file and the other into the Xcode project as a
project property.
The previous implementation forced developers to set both of them to
the same value to have consistency in the project. This is not nice
behavior.
The new logic allows setting only one of the two, which will then be
reused for the one left unspecified. This is more user friendly.
Finally the bundle identifier prefix was never escaped, which could
cause issues during code signing if it had invalid characters.
Now we escape the prefix to ensure the whole identifier is valid.
Amends 4d838dae5a
Pick-to: 6.2 6.3
Task-number: QTBUG-95838
Change-Id: I1448bd643893751c281cc0ea41c763d1bd03360e
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This ensures that the Xcode 'Display name' input under
${target} -> General -> Identity -> Display name is not empty.
Because adding ${PRODUCT_NAME} directly in the Info.plist.in template
will cause CMake to evaluate it as variable expansion, work around the
issue by putting the dollar sign into a separate cache variable that
after evaluation will result in ${PRODUCT_NAME} being in the file
verbatim, so that Xcode evaluate it at build time.
Amends 4d838dae5a
Pick-to: 6.2 6.3
Task-number: QTBUG-95838
Change-Id: I2d1090cc8e84b32442f7daca2d4ce5e3ad413c68
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Currently our iOS CMake toolchain file sets the global
XCODE_EMIT_EFFECTIVE_PLATFORM_NAME property to OFF, to work
around a CMake issue regarding usage of object libraries in
conjunction with Xcode. The error was
The OBJECT library type may not be used for IMPORTED libraries under
Xcode with multiple architectures $(CURRENT_ARCH)
While this got rid of the error, it introduced a regression where
linking an executable against a static library in the same project
failed due to the library not being placed in a directory where Xcode
expects it to be.
clang: error: no such file or directory:
'~/build-untitled4-Qt_6_0_2_for_iOS/Debug/libuntitled4.a'
The actual library is created in Debug-iphoneos/libuntitled4.a
Note the -iphoneos suffix, which is related to the
EFFECTIVE_PLATFORM_NAME.
This could be further worked around by either explicitly setting the
library ARCHIVE_OUTPUT_DIRECTORY property in the project, or flipping
the value of the XCODE_EMIT_EFFECTIVE_PLATFORM_NAME to ON at the
end of the project. Both workarounds are not project-friendly.
In the mean time CMake got a fix for the original error
at https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5771
which got released with CMake 3.20.0.
That was unfortunately not sufficient to remove our initial
workaround, because removing it would trigger a different
error at generation time
CMake Error:
Error evaluating generator expression:
$<TARGET_OBJECTS:Qt6::Quick_resources_1>
The evaluation of the TARGET_OBJECTS generator expression is only
suitable for consumption by CMake (limited under Xcode with multiple
architectures). It is not suitable for writing out elsewhere.
Fortunately, another fix landed in CMake 3.21.0 to address that
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6161
Because static builds (iOS) require CMake 3.21, with both of these
fixes we can now remove our workaround.
Even projects that set ARCHIVE_OUTPUT_DIRECTORY or flip
XCODE_EMIT_EFFECTIVE_PLATFORM_NAME to ON still continue to work
fine.
This also fixes installation of libraries, which also took into
account the effective platform name and thus caused a mismatch between
the expected output dir and the real one.
This reverts 1e1805ed36
Pick-to: 6.2 6.3
Fixes: QTBUG-93268
Fixes: QTBUG-95381
Task-number: QTBUG-87198
Change-Id: Ifcaf0f89e4328ae9859c596882ce32401fa491c3
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
When calling qt-cmake on the command line, we don't usually force
usage of a particular CMake generator and defer to the user's choice
or CMake's default for the host OS.
In the case of iOS, the generator that makes the most sense to use is
Xcode. One could also use Ninja / Unix Makefiles if the project
is only building static libraries, but for shared libraries and
executables the project likely needs the code signing
provided by xcodebuild.
When targeting iOS, use a different qt-cmake file template.
The iOS-specific shell script will set the CMAKE_GENERATOR environment
variable to 'Xcode'.
If no -G or -D CMAKE_GENERATOR is provided on the command line then
the project will use the Xcode generator. Otherwise the generator
given on the command line takes precedence.
The CMAKE_GENERATOR environment variable from the parent process is
completely ignored.
The logic is only done for iOS, to reduce the likeliness
of breaking the qt-cmake script for other platforms.
Note that Qt Creator does not use qt-cmake, but rather calls cmake
directly with additional options like the toolchain file,
architecture, sysroot, etc.
[ChangeLog][iOS][CMake] qt-cmake now defaults to using the Xcode
generator when targeting iOS projects.
Pick-to: 6.2 6.3
Fixes: QTBUG-100834
Change-Id: I39b3dce47cc9ee2f98678631e4bd035c59c65294
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Previously we picked the first reported team id as found in the Xcode
settings file.
Now we pick the first non-free team id if there is one, otherwise we
pick the first free one. This aligns with qmake behavior.
Using a non-free team id usually leads to fewer issues with automatic
code-signing.
[ChangeLog][iOS][CMake] A non-free Xcode team id is now preferred for
project signing.
Pick-to: 6.2 6.3
Fixes: QTBUG-96341
Change-Id: I58618fe5c6ca04184812e9bf955a9cb0b3842447
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
As far as I can see, the default is already 'Automatic' when it is
not specified, but it does improve some xcodebuild error messages in
certain edge cases if the option is specified explicitly.
Note that setting the style to Automatic will not suffice in order
to build the project from the command line with xcodebuild, if there
is no existing provisioning profile for the project in
~/Library/MobileDevice/Provisioning Profiles
You either need to build it once via the Xcode GUI, or you need to
call
xcodebuild -allowProvisioningUpdates
which will try to create / download a provisioning profile from
Apple's server.
This implies that Xcode must have been launched at least once,
and configured with a valid Apple developer account, including
a free account.
qmake already generates a Makefile that calls
xcodebuild -allowProvisioningUpdates.
CMake doesn't have a Makefile wrapper, so calling cmake --build .
will call xcodebuild directly, which again means users need to pass
-allowProvisioningUpdates explicitly.
It does not look like CMake intends to call it automatically
any time soon, see
https://gitlab.kitware.com/cmake/cmake/-/issues/22615
We intend to teach Qt Creator to add the -allowProvisioningUpdate
option when building a project using CMake.
The code sign style will not be set if the target
XCODE_ATTRIBUTE_CODE_SIGN_STYLE property or the
CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_STYLE variable has a value.
There's also an opt-out variable called
QT_NO_SET_XCODE_CODE_SIGN_STYLE
Pick-to: 6.2 6.3
Fixes: QTBUG-96347
Change-Id: If65ccb8a0393ff6d80e6caea3b8003fc59a8a62a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This matches what we do with qmake, which means a build application
can be deployed to either an iPhone or an iPad by default, without
having to fiddle with Xcode settings.
The device family will not be set if the target
XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY property or the
CMAKE_XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY variable has a value.
There's also an opt-out variable called
QT_NO_SET_XCODE_TARGETED_DEVICE_FAMILY
Pick-to: 6.2 6.3
Fixes: QTBUG-100833
Change-Id: I8cde10975b44af81cfa18f985523c8ec1529386d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Output names of static libraries might be different from target names.
For example, the library name of Qt6::DeviceDiscoverySupportPrivate is
"Qt6DeviceDiscoverySupport.lib", and the library name of
Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib".
This commit make pdb files names consistent with the library names.
And make sure we have set correct OUTPUT_NAME property before calling
qt_set_common_target_properties()/qt_internal_set_compile_pdb_names().
Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
When XCB_INPUT_TOUCH_BEGIN closes a popup, we then receive
XCB_INPUT_TOUCH_END, and cannot find a target window (because it's
destroyed). If we don't deliver it, we need to at least clear the
stored point from QPointingDevicePrivate::activePoints. Then when
we deliver the next touch press, m_fakeMouseSourcePointId also
needs to be reset.
It's now even more paramount that autotests (and real-world
touchscreens) must never omit any active touchpoint from a touch event.
If a point doesn't move, it must be included in the QTouchEvent, with
Stationary state. If not, QGuiApp::processTouchEvent() could generate
multiple TouchBegin events in a row, which gets other bits of logic
confused, here and there.
Fixes: QTBUG-94557
Fixes: QTBUG-98519
Fixes: QTBUG-102751
Fixes: QTBUG-103706
Pick-to: 6.2 6.3 5.15
Change-Id: Ia95e410a2bb8bc7784aa5d296fac2b89e53a9f55
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Sometimes it is not desirable to include the libraries in the APK,
e.g. system and vendor apps could prefer having one set of libraries
installed on the device. If unbundled deployment is specified,
native libraries will not be included in the APK.
With unbundled deployment, optional arguments can be passed to
set the path to load the libraries on the device.
[ChangeLog][Android][Deployment Changes] Adds option for Unbundled
deployment, where native libraries are not packaged in the APK.
Task-number: QAA-771
Change-Id: Ica51ef83a24dad58c7586bf610a58abe21fc1100
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
