The struct will likely gain qtcrunnanable/terminal members,
better pass all to where it is needed.
Change-Id: Ieb0dae8b56ce5c0992955dbfc0cd89cdd7bfe848
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Move some code around to make interfaces slimmer.
Also no need to check canHandle() twice per creation.
Change-Id: I7c86e2dc78ebd53a0f8e9609e9fa135aaf31e7b7
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It has been used twice on each Target::updateDefaultRunConfigurations():
Once to help filter out potentially interesting factories, and then
to actually retrieve the creators from the interesting factories.
The same result can be obtained with less effort and less code.
Change-Id: Ic83423bbbc172c842ec5a55fcd6ad83106e268aa
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
In line with addSupportedProjectType, saves a few cycles due to the
non-use of the temporary list, and in theory more flexible than the
existing set...(QList<Id>) as it potentially allows dependent plugin
to declare support for already existing configurations instead of
re-implementing their own.
Change-Id: I2b83e90de49daa9bfce6f780c5f51c2e971eb7d1
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
So far we used device type in some cases, not even following a specific
pattern.
Showing the device name gives a bit more detail in cases of multiple devices
of the same type and offers the user a bit more control on what it shown.
Change-Id: I2bd6bbd404577db3afca0f84b8a976cb07b1cfd0
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Instead of calling twice for AutoCreated and UserCreated, call once
and record to which case it belongs. Only the 'both' and
'user only' combination are ever used.
Change-Id: I9c15085bcbb4bf6584a6156135f2084dbfc51c1c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This was previously intented to be used in the RunConfig Add... menu,
but this role is now taken by RunConfigurationCreationInfo::displayName.
This fixes also a regression for setups that relied on
QmakeProject::buildTargets() and a fix up empty display names later.
Change-Id: If75fc79efbdedc918a126e50c962fc188d7a3ebc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This was already almost the desired final pattern, so make it the default
implementation of ProjectRunConfigurationFactory::availableBuildTargets.
For the only remaining feature of "decorating" the build target names,
introduce a property m_displayNamePattern.
Un-adapted sub-classes still need (and are able) to overide.
Change-Id: Ia7d2d2f7d53f8b1da487fa82c8265ad5deb47500
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... including build target name and display names instead of
returning QString build target names and producing display names
via displayNameForBuildTarget()
This is a mechanical intermediate step on the road to use
Target::applicationTargets().list uniformly as source of build
targets.
Change-Id: I7b0b1fb398d5061b0cec0b86890f9eaf0bb53a19
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
To be used for "special" build targets (Custom executables etc) that do not
depend on the project. This reduces user side boiler plate in a couple of
cases and is a bit clearer than the magic {QString()} result anyway.
Change-Id: I105b6ab952981143b2abf9b218fed30cee80b648
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... by additionally keeping local (currently non-owning) pools per
"interesting" type.
Current situation:
- The global object pool does not scale well for looking up
objects, as iteration plus qobject_cast typically iterates
over all pooled objects.
- User code that can use typed results from the object
pool need to have access to the full type definition anyway,
i.e. depend on the plugin of the target class anyway.
The patch here solves the scaling problem is to have local
type-specific pools to which objects register in their
constructors and deregister in their destructors.
This patch here does *not* change the ownership model of the
pooled objects, however, it opens the possibility to change
the ownership model per type (e.g. by not putting things into
the global pool at all anymore and make the local pool 'owning')
and the intent is to handle that in later patchs.
Even without the follow-up patches this here is a performance
improvement for the cases that access the local pools instead
the global one, i.e. "practically all".
Change-Id: Ib11a42df2c4ecf5e1155534730083a520dd1995b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
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>
This shifts the resposibility of creation/splitting of RunConfiguration
ids into what are essentially "type ids" and "build targets" to the base
implementation, possibly opening the path of abandoning the mangled ids
in favor of explicitly storing their constituent parts.
Take advantage of base id split in RunConfigurations for availableIds
/displayNameForId and for canCreate/canRestore/canClone.
Change-Id: I19fefb32757407ab5053a2ae0e5a79438659f6ec
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Filippo Cucchetto <filippocucchetto@gmail.com>
Do not add newlines when output gets flushed.
Task-number: QTCREATORBUG-17403
Change-Id: I0dea3a15611fcde8aa8cbc5fbc6b7f22c9c40dd7
Reviewed-by: hjk <hjk@qt.io>
All RunConfiguration factories had some kind of canHandle(Target *)
implementation. Centralize this notion.
Change-Id: Ie24a355e857bddfd76b866859b8c7a42ffc83840
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The pointer passed in was assumed to be non-null, but that does not need
to be the case.
This should make the function more robust in face of errors. The RunControl
passed into the method is taken from a QPointer. So if the RunControl is
destroyed, that pointer may be nullptr.
Task-number: QTCREATORBUG-19269
Change-Id: I42e7b9d5582df2ee0830c8f92af4e4a97e7d6417
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Moving aspect data closer to real Value semantics fixes
the regression introduced by 890c1906e.
Task-number: QTCREATORBUG-19186
Task-number: QTCREATORBUG-19192
Change-Id: Ieaeef3995ae06a817f266c1e2514f9e5793bd4e8
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It's not meant to ever change after contstruction.
Change-Id: I912b58dfb70b40c9763b902650d2c657c28ccc5c
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
For targets such as remote Linux, we would run all run configurations on
the remote device, even "custom run configuration", which is explicitly
intended for running locally.
Task-number: QTCREATORBUG-19121
Change-Id: I83d6bdd8a47440047d230266845286715432604a
Reviewed-by: hjk <hjk@qt.io>
The exectuable path in the user output was always converted to native
separators, even for non-Desktop targets.
Change-Id: I5b43b2da8a2b791472a1fd58940b179dcbaa28d0
Reviewed-by: hjk <hjk@qt.io>
Useful in some more complex setups.
Defaults to the tradionally unconditional reportFailure().
Change-Id: I26acaace1fa1e12caf83b785e4be539d8af7eb73
Reviewed-by: Filipe Azevedo <filipe.azevedo@kdab.com>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This moves the explicit build step into a dependent runWorker,
making the whole setup more aligned with a normal tool run.
Change-Id: Icd01b2e82f7f95774434d2ede04d08a5311b64e7
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
If a RunWorker fails to report success or failure (should not happen in
theory, but has been observed in practice, typically in exceptional code
paths) the RunControl will stay in 'Starting' or 'Stopping' state
forever. Give the user the opportunity to force a 'Stopped' state by a
second (or when 'Running' a third) time on the Stop button.
Change-Id: Iec58434927777bd67bfe01c5144ee5695b4d6cf1
Reviewed-by: Christian Stenger <christian.stenger@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>
Failures during RunControl construction currently get not to
the user as the Application output pane is not yet available.
In theory it should not happen, rather the condition should
be checked to disable running entirely, but in practice it
can happen e.g. in the BareMetal setup right now.
To avoid pre-release code restructuring, force a message box
in such cases.
Change-Id: I703c47b270d153afff34e08dad7833540a5983a2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
To be used for short-lived tasks to signal that they are done.
Essentially an optional reportStarted() followed by reportStopped()
Using it in GdbServerPortsGatherer when the port list is ready fixes
the wrong "un-stopped" situation in RemoteLinux debugging when
the inferior finishes by itself.
Change-Id: I310831a7875fe6f2c598302b73cda6c9669efb1d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
An essential RunWorker triggers the whole RunControl to stop if it
spontaneously stops.
Change-Id: Ia05b927e306022e99b45cc8cd7ab9636f4d3c129
Reviewed-by: hjk <hjk@qt.io>
Can happen on worker startup, e.g. missing binaries, permissions, ...
Change-Id: Ibeee0a6992af80d3486b00890664e83525f17204
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
It is always acted upon essentially the same as Done, but
complicates the scheme.
Change-Id: I8d9161fb162195a533c7ed29e251c3f486479dc9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There is no point in e.g. keeping the QML profiler RunWorker going if
the process has spontaneously stopped.
Change-Id: Ifdae17231cb193fd220397fa0739a74871ceeab3
Reviewed-by: hjk <hjk@qt.io>
A run worker will only be stopped if all its stop dependencies are
stopped.
Change-Id: I16a42253874adafb9ca87d175bfb361fae46cc39
Reviewed-by: hjk <hjk@qt.io>
There will be stopDependencies, too, which apply when stopping the
runcontrol.
Change-Id: Id72771d28cbb6b254572c9f93db93e0d054b890f
Reviewed-by: hjk <hjk@qt.io>
Returns true if the ProjectConfiguration element is currently active
and false otherwise.
Just a convenience method.
Change-Id: If75809ae7e78149d264deaaf6adc4ca8a8be43c2
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
... and use this as a base for all RunConfigurations.
Clean out code in the individual run configurations dealing with their
enabled/disabled state.
Change-Id: Icc2ea136b056f7aea7ce96480b4402459d7ac0ce
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Ensure that RunControls ramp down asynchronously.
Since RunControls now ramp down asynchronously the plugin can
only report synchronous shut down if no RunControl/OutputPane
was present.
Task-number: QTCREATORBUG-18605
Change-Id: Ib8d1f857f85c74d4f18ecb85db537121a2275668
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
