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>
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>
... and adapt constructors to not take the now-unneeded
RunConfiguration pointer.
Change-Id: I53ff338f51334ff7b0c22d4bed92bfcfc8225ea7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This patch gets rid of soft asserts regarding empty history key
and a warning when trying to store these into the settings.
Change-Id: I64440ebe7ae1fca660a1dc66a1646da5d17798bf
Reviewed-by: hjk <hjk@qt.io>
We have nowadays two ways to pass data from run configurations to
tool that do not require intimate knowledge of the sender:
1. Using RunConfigurationAspects, accessible for all workers in a
RunControl
2. Using RunWorker::recordData for an individual worker.
This removes the need to use specific fields in a runnable and
means that a tool plugin can be better separated from target plugins.
The approaches are not mutually exclusive, both use an string-ish
id, I chose here to use the same string when using both.
This patch here uses approach 2. for the GammaRay/Android combo.
It also fixes a (harmless) typo (s/POSTSTART/POSTFINISH).
Change-Id: I4048693ca73b17253a39bfcacc9e1880ecf25736
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
The base AndroidRunConfiguration as such is buildsystem agnostic now,
it is, however not usable with other buildsystems as the apk build
step relies on qmake specific information, so the run configuration
factory stays on the buildsystem specific side for now.
Change-Id: I00538846028cc060aceea15ffd2e63068450f1e8
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
Note that the concept of a single monolithic OutputFormatter per
RunConfiguration (and why RunConfiguration, not RunControl to start
with?) is unchanged and suboptimal as one cannot easily combine
existing use cases, e.g. Python_and_Qt.
Change-Id: Ibeb8191020387324f22ed313230293597f96e36a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This follow the rough pattern of recent *RunConfigurationFactory changes
for build and deploy configurations.
- Collapse the two lines of constructors similar to what
890c1906e6 did for RunConfigurations
* Deploy* was purely mechanical
* Build* ctors are split in connects() in the ctor body
to create "empty shell for clone" etc
and build step additions in initialize() functions which
are only used in the create() case.
-- Allows to collapse the shared 'ctor()' functions, too.
- Move FooBuildConfigurationFactory::create() implementations
to FooBuildConfiguration() constructor. That was a strange
and unneeded ping-pong between factories and objects, and
furthermore allows one level less of indirection (and for a
later, left out here, some reduction of the
FooBuildConfiguration interfaces that were only used to
accommodate the *Factory::create() functions.
- Most {Build,Deploy}Configuration{,Factory} classes had a canHandle(),
but there wasn't one in the base classses. Have one there.
- Most canHandle() functions were checking simple restrictions on
e.g. project or target types, specify those by setters in the
constructors instead and check them in the base canHandle()
- clone() is generally replaced by a creation of a "shell object"
and a fromMap(source->toMap()), implemented in the base, there
are two cases left for Android and Qbs that needed(?) some extra
polish
- generally use canHandle() in base implementation, instead
of doing that in all Derived::canFoo()
- as a result, canCreate/create/canClone/clone reimplementations
are not needed anymore, keep the base implementation for
now (could be inlined into their only users later), but
de-virtualize them.
- Combine Ios{Preset,DSym}BuildStepFactory. There was only one
'dsym' build step they could create.
- Split the 'mangled' id into the ProjectConfiguration subtype
specific constant identifier, and a QString extraId() bit.
Only maintain the mangled id in saved settings.
- Make ProjectConfiguration::m_id a constant member, adapt
all constructors of derived classe.
Not done in this patch:
- Finish possible cosmetic changes on top
- Add a way to specify restrictions to supported Qt versions
(used in Android/Ios), as the base implementation does not
depend on the qtsupport plugin
- Combine the QList<X> availableFoo() + createFoo(X) function
pairs to somthing like a direct
QList<struct { X; std::function<X()>; }> fooCreators()
to avoid e.g. the baseId.withSuffix() <-> id.suffixAfter(base)
pingpong
- Remove the *Factories from the global object pool
- Do something about priority(). Falling back to plain
qmake in android+qmake setup is not helpful.
Change-Id: I2be7d88d554c5aa8b7db8edf5b93278e1ae0112a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The idea is to massage the setup in a way to make implementation
of new configurations less error prone by identifying recurring patterns
and sharing repetitive code that tends to be forgotten (see Android cloning).
The former two lines of constructors (owner-and-id, owner-and-source)
are split into a simple, shared, constructor and new setId() and
copyFrom() functions.
The change is mostly mechanical, some multiple calls to fromMap
have been removed, though, some consts added.
Otherwise, to keep the patch small it temporarily introduces two
helper templates in IRunConfigurationFactory. Also, setId() signatures
have not been unified yet. These won't be needed in the final setup.
Change-Id: I8c0734496caae744a9883fe6d92c1d8f8e0234ea
Reviewed-by: hjk <hjk@qt.io>
Let user specify list of shell commands to run before app starts
and after app quits.
Change-Id: I9794fb96180530ca6c28ce6581fda51a25be28d4
Reviewed-by: hjk <hjk@qt.io>
This moves all of the RunControl implementation into a single
RunWorker, not yet splitting it up into separate RunWorkers
which is the final goal of this series.
Change-Id: I7373105603505aa4fffd7fe5ff0145f0128b34bc
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
- allow the user to choose the visible log levels
- allow the user to choose which activities/service(s) logs are visible
- wakeup the device (API 20+)
- use only the most recent logs (API 21+ add "-T 0" to logcat params)
- use logcat -v time format, which is the same on all Android versions
In the future we can even allow the user to choose which parts of the
log line are visible, e.g. time, log level, TAG, PID, Message
Task-number: QTCREATORBUG-16887
Change-Id: I07ce00aff59a479660f5ac6da75eef973ba3f627
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
The plan is to eventually move the qmake specific class into the
qmake plugin.
Change-Id: I5653c45ed88b1be296f4963ab4117bbfa791fb85
Reviewed-by: BogDan Vatra <bogdan@kde.org>
Make it possible to create multiple AndroidConfigs so that we can have
a different one in the settings dialog from the global one. Move pretty
much every method from AndroidConfigurations to AndroidConfig, so that
the settings dialog can work with its copy. Also add some additional
logic to the settings page around the java setting. To start the avd
manager we need both a sdk path and a java path. Also do some basic
additional checking of the java path.
Task-number: QTCREATORBUG-7724
Task-number: QTCREATORBUG-10936
Task-number: QTCREATORBUG-10937
Task-number: QTCREATORBUG-11059
Task-number: QTCREATORBUG-11218
Change-Id: I148c69b9c98a8a070d17d9b0e223d01db1750e69
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
This affects mainly Apple's version of GDB. Mac users are advised to
use LLDB, or some recent build of FSF GDB.
Change-Id: I6a7fbb591e79f737e12d08b0e881e9e4d1d9660c
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Disable the runconfiguration if the project could not be parsed.
Change-Id: I979315b5e38fd1d8674da68289e021e014070c54
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Creator now realiable creates one toolchain for each toolchain found in
the ndk. This no longer depends on any qt versions being present.
Also the gdb command and gdb server command are moved to the Kit and are
no longer found in the Android Options page. Both settings can be
autodetected from the Kit options page. Note that this might break
existing android kits.
Change-Id: I1dce084f2bb372e615e19b1c9e3a1e205b5d9647
Reviewed-by: BogDan Vatra <bogdan@kde.org>
* Rename profiles to kits.
* Update some strings:
* projects mode has a Kits tab, not a Targets tab.
* " Settings" was dropped from the sub-tabs of the Kits tab
* menu entry "Build/Open Build/Run Target Selector" was renamed
to "Build/Open Build and Run Kits Selector".
* Use "Kit" instead of "Target" in miniprojecttargetselector.
(The class was not renamed as it does indeed select targets,
not kits)
Change-Id: I0727e086e2dfa0e8aaaf89fdc6f2e3596c7a4314
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
More Profile use, less dependency on QtSupport,
Derive qtVersionId from profile instead of qt build configuration.
Replace qt4BuildConfiguration with buildConfiguration.
Use IDevice base class in AbstractRemoteLinuxApplicationRunner
and in other places. Simplify remote linux runconfiguration
Change-Id: I6414d3d8146d16c360b3a0465c57a052ea71f899
Reviewed-by: Christian Kandeler <christian.kandeler@nokia.com>
Introduce Profiles to store sets of values that describe a system/device.
These profiles are held by a target, getting rid of much of the information
stored in the Build-/Run-/DeployConfigurations, greatly simplifying those.
This is a squash of the wip/profile branch which has been on gerrit for a
while, rebased to current master.
Change-Id: I25956c8dd4d1962b2134bfaa8a8076ae3909460f
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Use Core::Id for all the project related objects in favor of plain
QStrings.
Change-Id: I790ab40cb29899efdb49c413a77609486f52e683
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
