Unused now, and arguably not a valid concept anymore.
A run control may consist of different runworkers,
'operating' on different systems.
Since the removed RunConfiguration::abi() implementation uses
only public Target ABI, user code could revive that locally
in case it was needed again.
Change-Id: I658c6e88b4a1aec18bf4de91fc86230552bc0710
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Using aspects is the standard pattern nowadays, there's nothing 'extra'
to them anymore.
Change-Id: I446f9d7b1db58a4899e5e44df33ce51f655e7be4
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
... into items that can be used generically in project configurations
(ProjectConfigurationAspect) and items that have a choice between
global and project settings (GlobalOrProjectAspect)
Change-Id: I94831237bdbb18c339eb76eba131bf7f928933d6
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
... and adapt constructors to not take the now-unneeded
RunConfiguration pointer.
Change-Id: I53ff338f51334ff7b0c22d4bed92bfcfc8225ea7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
To remove the last user of IRCAspect::runConfiguration.
Change-Id: I1390166730112008a4050877f96bb29f274e7ef1
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This avoids four uses of IRunConfigurationAspect::runConfiguration()
which is meant to be removed soon.
Change-Id: I7a8f0a09b0a90042b0855b18e5be875bd343268c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This avoids one use of IRunConfigurationAspect::runConfiguration()
which is meant to be removed soon.
Change-Id: Ib394a71b6bb7a6c028fc533656454b94895f6451
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
... instead of directly accessing the owning runconfig.
The removes two uses of IRCAspect::runConfiguration()
which is meant to be removed soon.
Change-Id: Ia713864f2544e3c6741482b2663ee54fd2ee80e1
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Split the remaining manually managed data into a standard ArgumentsAspect
and a new MainQmlFileAspect.
Change-Id: I8a8fe3f4a08d602a7b6e9c9463d3d7de257b6e6c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The actual remaining use was to pop up a terminal in some
setups where Mode == Console, with a default of Gui meaning
"no console". In some downstream uses it was used set to
Console (probably to mean "this helper process does not need
a gui") but then luckily ignored when actually starting the
helper processes.
All cases where the console is useful and requested are
nowadays RunWorkers belonging to RunConfigurations with
a TerminalAspect, so they can directly get the relevant bit
from their RunConfiguration without having it part of
all StandardRunnables.
Change-Id: I1368d5968da5cf672656aebf200ccac8d45335d0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This avoids the "catch all" that leads to conflicts with more specific
setups like the AppManagerRunConfig, and consequently lets us remove
the priorities in the RunWorkerFactories.
Change-Id: I382f00ca7f759eef995ac6fe749bb371ab027020
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
As all Runnables are known to be StandardRunnables, this here
essentially replaces all .is<StandardRunnable> by 'true'.
.as<StandardRunnable> by no-op, and fixes the fallout.
Change-Id: I1632f8e164fa0a9dff063df47a9e191fdf7bbb2e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It's what the base class requires, and opens the possibility to
have several factories creating the same type of run configuration.
Also move ios, winrt and android factories closer to their products,
it's the predominant pattern nowadays.
Change-Id: Iad48152f02a248d22cb18dd435a2fc34d73c7077
Reviewed-by: Christian Kandeler <christian.kandeler@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>
No need to have a dozen lines of code in a separate translation
unit and more in line with what others do nowadays.
Change-Id: I765535d1484805bc3005fe23bfd4992a96a80e9c
Reviewed-by: hjk <hjk@qt.io>
This fixes a regression introduced by
30638df441.
Custom import paths have to be absolute for the code model.
Change-Id: I232229fa58c3900fe684ca4529b2ed08bf93e8be
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
On desktop the target directory is the same as the source directory. On
remote devices, it can be different. We need to resolve when we know
where to deploy.
Change-Id: I3f2bc088476ae73dac5231cb24f277c055f7d044
Task-number: QTCREATORBUG-19888
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
We add a "targetDirectory" property to the file format and fill in the
deployment data.
(cherry picked from commit fba61c5b55)
Change-Id: If207cd5c77175c54cffdb5df92ea85c425cd3191
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
qmlviewer is QtQuick1 and not supported anymore.
The qmlscene command is in general not a property of the Qt version but
of the target device, as we generally assume Qt binaries to be
preinstalled on the target and qmlscene is executed on the target.
DesktopQtVersion retains a method to retrieve the qmlscene path as there
target == host and having the method available enables us to warn if the
binary is missing.
Also, QmlProjectManager needs to pick the qmlscene command from the Qt
version if it's a desktop Qt.
Change-Id: I2ee0f993e60b96d672080db2db0a6abe5ca933e3
Reviewed-by: Thomas Hartmann <thomas.hartmann@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>
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>
Right now, the qmake project manager offers a "Build" context menu entry
for .ui.qml files and various other things are off because the mime
types are different.
Change-Id: Icc966e56513b9c5aed05f929dc8cb728ed408723
Reviewed-by: Thomas Hartmann <thomas.hartmann@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>
... 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>
To avoid repeating the 'MimeDatabase mdb; mdb.something(); ' mantra
all over the place.
Change-Id: I4bfef62e73275a991455141671d6071162788e9d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The functionality can be provided by producing a suitable Runnable
in the derived classes directly.
Change-Id: I7b8e8fe33fffd2b00176b6cf6633eca4e152e466
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
We registered a mime type "application/x-qml" conflicting with "text/x-
qml" from freedesktop.org.xml. The magic matcher of the C++ mime types
might kick in, in that case.
Task-number: QTCREATORBUG-13994
Change-Id: I5900c233b42681d7b7d3af185d6ff3e1c4166e59
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
