The CMake templates still point to information that apply only to Qt 5
when it comes to settings Android properties. This updates the template
to show the right way to define Android target properties on Qt 6 as
well.
Task-number: QTBUG-94597
Change-Id: I28e3dbd93eca352502b3d1b584f02924e2478c07
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Amends 40181057cd
Complained that the Q_DECLARE_METATYPE comes too late.
Change-Id: Id5dd355fadcb4a6790d4c74dd1c637e0b1569aa4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Mostly for informational purposes. Helpful e.g. to check whether
an auto-detected cmake binary from a docker device matches
expectations.
Change-Id: I546b0ab6edc240cc779bbf0560e00165cb524fcb
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Currently, in d'tor of ModelManagerInterface, when joinAllThreads()
has finished, we were setting the g_instance to nullptr. However,
just after the joinAllThreads() has finished and before setting
the g_instance to nullptr some other thread could still add a
new future and this thread could potentially still assume that
instance() will return valid pointer.
The fix is to make joinAllThreads() and setting the g_instance to
nullptr in an atomic way. We ensure, that when there are still
pending futures, we don't clear the instance, but call joinAllThreads()
again for them.
The implementation is similar to what we do in test_joinAllThreads().
Change-Id: I99dc341228aee710a958a0fbc6c5ec1fbe132e7f
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
Add ModelManagerInterface *ModelManagerInterface::instanceForFuture()
method. If the returned instance is not null, it's guaranteed
that it will be valid at least as long as the passed QFuture object
isn't finished.
Use instanceForFuture() in Link c'tor, as it's called from
non-gui thread.
Change-Id: I7e5ee6ad27e8f71cc0cef7fd9a91b710e2f8f662
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
Synchronize all the running futures on shutdown. It's enough
that all threads started by runAsync() just finish, without the
need for delivering the results of these futures to onFinished
handlers.
Fixes: QTCREATORBUG-25350
Change-Id: Iac5ae3834bb02ef0a77b063c59097471ec7e757d
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
The idea in this approach is that we only collect those futures,
which have resulted from runAsync. The assumption is that
all tasks associated with those futures may sooner or
later finish, without the need to call qApp->processEvents().
OTOH, we don't collect fake futures coming from Utils::onFinished,
as these requires the spinning event loop in order to deliver
the onFinished signal.
So, the new joinAllThreads() method waits for all collected
futures to finish. We also _do_ want canceled and not finished
futures to finish, since even when they are canceled,
they may still be running and using the internals
of possibly destructed ModelManager. This means, we are only
waiting for other threads to be finished, without reporting
their results to e.g. onFinished() handlers.
Some tests require that all onFinished handlers are also processed.
In order to achieve this, we create a loop inside
tst_joinAllThreads() method and we call joinAllThreads(), so
it will wait for all pending queue to finish, and then we call process
events, in order to let finished futures propagate their results
to their respective onFinished() handlers.
Some handlers may have stared another threads when being processed,
so we may expect that some new futures will appear.
So, after processing the events we check if any new events
appeared, and in this case we repeat the loop.
Otherwise, we finish synchronization.
Amends: 96c860159b
Task-number: QTCREATORBUG-25350
Change-Id: I5e44150c55f6be00445a5695938482d948990c94
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
When using "Expand All" before running tests we may miss
the results due to filtering that has not been applied
correctly.
Fixes: QTCREATORBUG-25877
Change-Id: Ibe6af43ff28e31c7acfd78ba3ec1daf9db620b56
Reviewed-by: David Schulz <david.schulz@qt.io>
Do not omit messages from death tests as they can be
essential to figure out what went wrong.
Fixes: QTCREATORBUG-25888
Change-Id: I30bc9856ae952dc30f4002a5bbc98245a524fae7
Reviewed-by: David Schulz <david.schulz@qt.io>
- Pass everything through the codec.
- Always emit even incomplete last lines when the process finishes.
- Don't store raw output when line-wise processing is requested.
Change-Id: I5cc30ad0d7ab79387bfb00b48ff957468a1bd004
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This is directly passed to cmake and used in the context of the build device.
Change-Id: If22764b0d962f96b51897b754b413c2310818c33
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
From ProjectExplorerPlugin::extensionsInitialize to initialize.
It's cheap, and needed for other plugins to access local file
operations via the generic IDevice interfaces.
Change-Id: Iefa31d4dcbe4c894756e5f42e5a6cc2b8aecf24f
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Search in build device path instead of two hardcoded locations.
Change-Id: I91e047aa48eb6566353e3ba090070c2a00b3dd06
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... and make use of them with clangd.
This way, users can get immediate feedback when a new proposal entry
has been found, rather than having to wait until all of them have been
collected.
Change-Id: I2adfe0153aa7a058f28eb3bd65c71dd30ea018e0
Reviewed-by: David Schulz <david.schulz@qt.io>
In the light of docker support it would be nice to have a way
to tell existing RunWorkerFactories that they also work for
docker, or generally to increase the scope to which they apply
after construction time.
Small con: Some more boiler plate,
Small pros: Setup using the new method looks similar to what we use
in the other factories, and the Factories types are recognizable
when debugging.
Change-Id: Idb1757f519e7151b835326aa8b98aeaa4a372cc4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Baby step on the path from hard coded to user defined.
Change-Id: I2536924c5ba07dadcbe3c94304d55db25f876987
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Even though build directories are later usually accessed "locally in
the context of a build device" even in true remote" setups it is easier
to reason about them if they follow the convention, especially as they
are used to derive other paths that might be used to access items in
a host context.
Change-Id: Ib831bdd1f81981ef96323dcb8d1cd21c31347c19
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Doesn't work correctly yet, it effectively runs in a host environment.
Change-Id: I2aaf7d1b04ca38f9a0825edf78e264ceaed0434b
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
We should check for the version. For this we have to enable
semantic errors.
Change-Id: I8bedca041ebf9bbc0580b89076203e47942cc539
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>
