... by using factory members in the plugin pimpl. This also
(intentionally) transfers ownership of the factories to the
plugins, effectively progressing on the "FIXME:"
in runcontrol.h:164.
Change-Id: Ia75ee034d25a75b5d5bff6b2fa2b3471347d1a14
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... and use in as replacement for RunConfiguration::addRunWorkerFactory.
It is still convenient to have a simple way to set up run worker
factories for the typical "just run for this configuration" case,
but it's even better if it follows the nowadays predominant pattern
of keeping factories in the plugin's pimpl.
Also, it turned out there were two copies of
QmlProjectRunconfigurationFactory code, one is enough.
Change-Id: I0b28c4ea18d0f52165a49f6133dc8687a3b9c7cf
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Also, construct the KitManager implicitly when the first
KitAspect is created. Ramp-down is still explicit and
somewhat odd.
Change-Id: If1506e1d0789ecabbaad2d8008851d0b42c5218b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The functionality of this function overlapped with KitAspect::setup(),
leading to unclear responsibilities and resulting in bugs such as the
one fixed by 776d54e435.
Therefore, we drop the defaultValue() function, merging its
implementation with setup() where applicable.
Change-Id: Iefa9c3df8b76e97ddf9ad388516621f7ea6558d4
Reviewed-by: hjk <hjk@qt.io>
Instead of creating and destroying in some cases only create the ones
that will be used.
Change-Id: I5c3200101ec21b4a4cf1e3c6e91bf94153278b5c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For a long time, probably from the very beginning, a RunControl
was meant to hold (a copy of) data needed for its operation, that was
valid at the time of its construction, to be resilient in cases
where RunConfiguration setting were changed while the RunControl
was running, or to properly re-run with the original settings.
Unfortunately, the task was repetitive, as RunConfiguration
classes had no generic access to properties / "aspects"
and there was was the runConfiguration() accessor (probably
for mostly unrelated reasons in the output pane handling) which
made the idea of just casting that to the original runConfiguration
and access the data directly there appealing, with all the
expected consequences.
This patch here partially addresses the issue by copying some
more of the related data at RunControl construction time and
adjust the using code, avoiding most uses of the runConfiguration()
accessor in a mostly mechanical matter.
Complete removal appears possible, but will be less mechanical
in "difficult" plugins like ios, so this is left for later.
The new accessors in RunControl are very much ad-hoc, leaving
room for improvement, e.g. by consolidating the access to the
run config settings aspects with the other runconfig aspects
or similar. For now the goal is to remove the runConfiguration()
accessor, and to as much as possible fixed data after RunControl
setup is finished.
Next step would be to officially allow construction of RunControls
without a specific RunConfiguration by setting the necessary
data independently, removing the need for the various workarounds
that are currently used for the purpose of faking (parts of) the
effect of the non-existing RunConfiguration or refusing to operate
at all, even if it would be possible.
Change-Id: If8e5596da8422c70e90f97270389adbe6d0b46f2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The interface of this function was rather unfortunate. In particluar,
the fact that it took ownership of the std::unique_ptr that was passed
in required some weird boiler plate code at all the calling sites.
Instead, it now becomes a proper factory function.
Change-Id: Iecdc6f6345232fc0f0a08bffaf8f1780edb57201
Reviewed-by: hjk <hjk@qt.io>
... at least logically a bit more into hunks responsible for
one of the possible choices of base environments.
This makes it possible to move code that modifies individual
cases closer to the only place that uses it.
Change-Id: I1c87bb869e04e44b92ff097b0bf25274f93808be
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Will help to streamline *EnvironmentAspect constructor signature,
which in turn will help to have a generic cloning mechanism to
clone aspect data, which in turn will help to finally execute on
the idea that RunControls should be re-runnable in their original
setup and also resilient to changes in the setup while they are
running.
Change-Id: Ibdaca487c1f7ce043e675fd014fe923a70273639
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Requirements:
- NDKr19 or newer
- Qt 5.12.1 or newer
QtCreator supports the following variables:
- ANDROID_PACKAGE_SOURCE_DIR
- ANDROID_EXTRA_LIBS
Be aware, that there is a lot of magic done on QtCreator side, and you
can't use only cmake to build an Android APK.
[ChangeLog][Android][CMake] Add Android support for CMake projects.
Change-Id: I1d351976ed56f424c2bc972f4ff7b5968147a2ed
Reviewed-by: hjk <hjk@qt.io>
Get closer to a uniform pattern of code layout (public/private,
pimpl naming...)
Change-Id: If2bc6dcee3df9127274f479b4ebc270d283dcb65
Reviewed-by: Xing Xiong
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Mainly to get rid of the QProcess::finished deprecation warning.
Also adjust coding style in the surrounding connects when needed.
Change-Id: I12f9b248c7974b892c4a069356e578e80f8c59e9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The formerly handled special case of a missing project file is
now handled by the base implementation.
Change-Id: Ib3f7d295395b5c406acbd8bdd578fd7190b34dae
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Except for the DesktopDevice, which is kind of special. Also try
a bit to make (and partially fail at doing so) naming and code
structure (#include, use of namespaces) more similar to each other.
Change-Id: I9fe266e706b72c14f59ff03ca1ae02dba3adcc71
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
A convenience wrapper for
applicationTargets().buildTargetInfo(buildKey),
the only context using the BuildTargetInfoList member.
Also, only one of the free comparison functions is ever used,
only in one place. Inline it there.
Change-Id: I7565e9d51d429af34352649e235243e5b3328fe9
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... by a mechanism that doesn't require re-implementation in each
derived class.
A QtVersion's type() is uniquely defined by the supported type of
the factory creating it, so that factory can be found and used
for cloning. Non-base data is copied by a fromMap(toMap()) dance
as done in the project configurations.
As a side-effect, the *QtVersion copy constructors are not used
and not needed anymore.
Change-Id: I3aa5a0fd90a27dd115769e0573647cb5669641a0
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Derived implementation either used that as-is, or used the
result as part of their own operation.
Change-Id: I2817c4e6c6701ae647a70e77382dd30c8ea2bd2f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
One instance had (base) qt version already at hand, the other was
inside AndroidQtVersion itself.
Also remove the typo in the function name.
Change-Id: I8fb0a1cd11751e4dea1f29a99603ea6b0112c49e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... by a functor checking some ad-hoc custom structure content.
This effectively replaces one ugliness (access to qmake specific
variable via qmake specific ProFileEvaluator) by an indirection
layer with similarly ungeneric contents, but I like the latter
setup better.
Change-Id: Iaee07c992fce4aabee2f4eae32a2413d772fe945
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... into a 'canCreate()' and the actual creation, which can be
done by the already registered m_creator.
Simpler interface, with the (temporary) regression that the
EmbeddedLinuxQtVersion get constructed twice, once only to
determine that it should be alive afterwards. Will be fixed later.
Change-Id: I5da2cafe473b25a0207bbd628632c9a259780361
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Use default plus polish afterwards instead.
Change-Id: Ibd137562128445a5bae5aaa4fc5fcce2df6c3e38
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Use two setters, one already pre-existing, to set autodetection
data instead of passing that through the create/contructor chain.
Change-Id: I8f9bdf2f82518aae765327a823bdea44210c2f96
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Test globally in advance instead. For two factories that means a stricter
check on the qmake executable but with qmake being a host tool the additional
exists/executable check should be in order.
Change-Id: Ib07ef19aeee2d0a19d4c38e178f3e20d22867c2c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Same pattern as for the project configuration factories.
Change-Id: Ia2f85eb2d787965f7a49be3bfe0be20c3f2aed8a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Similar to the various types of project *ConfigurationFactory
Change-Id: I7b721f127c8bcc13c7db6880d36c79dd091bc037
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The authoritative source of information about a KitAspect is the
KitAspect itself, not the associated widget.
Change-Id: I72d3d0425b845457846a940350bab59f1ff0cc2c
Reviewed-by: hjk <hjk@qt.io>
A KitAspectWidget class is tightly coupled with the respective
KitAspect, and no one else ever needs to see any KitAspectWidget
subclass at build time.
Change-Id: I1883af3b054c225e1ff5dd913118715bfdbaacfc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
The name "KitInformation" does not properly convey the fact that it
represents a certain *aspect* of a kit. The same goes for
"KitConfigWidget", which in addition was inconsistent with
"KitInformation".
We now use "KitAspect" and "KitAspectWidget".
Change-Id: I9804ee4cedc4d61fad533ea1dd4e4720e67fde97
Reviewed-by: hjk <hjk@qt.io>
The gdbserver is not uploaded to device for armv7 as lib symlink
is available and we can use the gdbserver packaged with the apk
Task-number: QTCREATORBUG-21317
Change-Id: I263eb48bbf3cf05b969db934a928185dba10373b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Originally, the build manager used to run all build steps in a dedicated
thread. Communication between the step and the manager happened via a
QFutureInterface that was passed into the step's run() function.
Later, new steps were added that operated asynchronously, so the build
manager had to differentiate between the different kinds of steps for
starting and stopping.
These days, almost all build and deploy steps work asynchronously, which
made the QFuture-based interface look increasingly odd.
With this patch, all build steps are expected to work asynchronously, so
the build manager no longer needs to differentiate. Steps are started
and requested to stop via the run() and cancel() functions,
respectively, and emit the finished() signal when they are done. Build
step implementors no longer have to deal with a QFutureInterface. For
steps whose implementation is inherently synchronous, the BuildStep base
class offers a runInThread() function.
Change-Id: If905c68b234c5a669f6e19f43142eaa57d594803
Reviewed-by: hjk <hjk@qt.io>
Sometimes it's imnportant where the cursor currently is
to properly format the code without affecting the current line.
Change-Id: I8b1fb11d2303adb5f960c7cb80a0ed2e6e45010f
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
Remove the nested QGroupBox, inline code into only callers, etc.
Also use better display name for deploy step widget.
Change-Id: I579810c04dea032a98ba28db6de035048f801f75
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
... to matching Qt and tool chain.
This is the only remaining place in Creator that refuses to restore
deploy configurations in such cases, and arguably there's no point
in dropping such a configuration as a whole, the individual steps
(i.e. AndroidDeployQtStep) can and do chicken out at deploy time
if there's no Qt version in reach.
Also move AndroidDeployConfigurationFactory to the plugin.cpp,
no need for a .cpp/.h pair for the remaining few lines.
Change-Id: If6ea7cf9573149c88c05629997ac582dc90d1e48
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
AndroidBuildApkStep are only ever inserted into the build step list,
never the clean step list.
Change-Id: I9a56bd045bf2434ac50649f3ce68209942c1ddba
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
