For cases where no genuine RunConfiguration is available.
Use it in the debugger for the cases triggered from the menu.
Change-Id: I5671f4f5db2547c4a7a70bd34292bb6ccc8e6bf4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Into a trivial bit and two setters. Plan is to use it only with information
that is truly there (e.g. kit/device only) at the user side without having
to invent a RunConfiguration "handle".
Also remove some dead code in the test runner.
Change-Id: I987881e41722178b14b91f973b84cbdb67a9f85e
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>
Use a signal directly now, the users know the caller.
Change-Id: Ib2ff4dbe3047eddf2a060eef060b487a4c17e78c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This was kind of done for AndroidRunConfigurations, but seems uniformly
applicable as all projects have something like a "project file"
currently.
Change-Id: I48e1887ea900181b5bf42f75fb9412379a8320dc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This is mainly there to make the local runconfiguration implementations
more uniform. Both qmake and qbs will drop runconfigs for builds that
are not available anymore, so that's a no-op for them.
Change-Id: I8aa32d779f67cce7a4d4733cfbe0c9a136bfd3f7
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This functionality was implemented via a pop-up menu, which was close to
unusable if more than a few candidates existed (for example: Qt Creator
with autotests enabled).
We now use a proper dialog. The list of candidates is sortable, can be
filtered and includes information about which project file the target
executable comes from.
Fixes: QTCREATORBUG-19955
Change-Id: Ife087ad69a7e43e280d13c528d21f94a1ae48d4d
Reviewed-by: hjk <hjk@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>
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>
... for otherwise identically-named targets.
It happens quite often in larger qmake projects that some applications
in a nested SUBDIRS structure get the same name (e.g. a tool and its
autotest).
It was until now impossible for a user to differentiate between the
corresponding run configurations: In the list of run configs, we just
appended numbers, and in the UI element for manually creating run
configs, the strings were even entirely identical. For a practical
example, open tests.pro in qtbase and count the number of run configs
called "test".
Now we detect such collisions early and append the relative path of the
project file to the display names of the affected run configurations.
For now, this is only done for qmake projects: The problem cannot occur
with qbs, and we don't have any complaints about cmake. The
infrastructure is generic, however.
Fixes: QTCREATORBUG-9563
Change-Id: Ic076df9b5a8bda7c9a1f88df683f33c837eaa197
Reviewed-by: hjk <hjk@qt.io>
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>
Instead, set the default level of all logs to QtWarningMsg.
The call to setFilterRules overrides the user preferences in qtlogging.ini.
Change-Id: Id5f6cd550d14ff7f45ae04c5d3110e0bafb0f072
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: hjk <hjk@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>
There are no external users left, so there's no need to expose
it in the header anymore. Also saves a cast.
Change-Id: I1ced368ebc9588cbc0058cc7d37f39ab80f9c595
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The only ever user (AppManager) doesn't need it for disambiguation
anymore.
Change-Id: Iea2f4d545bf9afb0610bf73c4ec7b2f29357edc0
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Do not add newlines when remote process output gets flushed.
Task-number: QTCREATORBUG-19367
Change-Id: I9e878695279404d436264abd580884fb6a9e91ad
Reviewed-by: hjk <hjk@qt.io>
... 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>
None of the run configuration aspects that are added to each runconfig
depend on the actual runconfig, only two need the target, the rest
nothing at all. So use target as common denominator.
Change-Id: I31829e63ac79d5c707bb068d73fc6a4687cb4c47
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
... and adapt constructors to not take the now-unneeded
RunConfiguration pointer.
Change-Id: I53ff338f51334ff7b0c22d4bed92bfcfc8225ea7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Not really needed, a QWidget does the job, too, and de-emphasizes
then 'Run' bit. The display name is now taken always from the
aspect, but that's what was the practically the case before,
albeit with different implementations.
Change all names to *[cC]onfigWidget* (in line with ISettingsAspect).
Change-Id: Ida0409a2dd0b175dd5ce4202f9b9e94b3f2db421
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
To remove the last user of IRCAspect::runConfiguration.
Change-Id: I1390166730112008a4050877f96bb29f274e7ef1
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
... when needed to avoid a use of IRCAspect::runConfiguration.
Change-Id: I0bdae0a2a1aad4475dd3225e6ae71da7bfd9513f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Instead of using a hard-coded list of well-known (optional) aspects,
add all aspects, so there is no need for special treatment of
RunConfiguration with unusual/custom aspects needed.
Price and benefit is that the individual run configs are again
responsible for the aspect display order which is determined
from the aspect construction order.
Change-Id: Iff2656b2e358c0f0f789d4c006a5c44d0a1536a5
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It has been an obsolete alias for setId for a while and downstream
uses have been adapted.
Change-Id: I467370aa67054599c7771e8275d28e62ddc461fa
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use unique_ptr for all *Private classes, except for those
in singletons.
Change-Id: Ib56c31ddedc6e9cf321f15de1f1e697a27ad4089
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>
There is a recurring special case that certain run controls depend
on the presence of specific RunConfiguration (which in turn has
it's own restriction on e.g. target or project types) but have no
further restrictions.
Make it easy to handle that case.
Change-Id: I2e86f366591b02003f720dcc00b4c52bb2f34e00
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>
With AndroidRunnable gone, there is only one incarnation of
a Runnable left - the StandardRunnable.
It is not expected to ever need a different runnable again,
as platform differences are now handled in the platform specific
RunConfigurations and RunWorkers created there locally, and
global information is typically communicated via
RunConfigurationAspects, so there is no point in keeping the
Runnable::{Concept,Model} machinery.
This patch here essentially makes StandardRunnable a type alias
for Runnable, to allow downstream changing all
if (r.is<StandardRunnable>()) { ... r.as<StandardRunnable>(); }
one by one.
When all downstream is adjusted, the alias can go completely.
Change-Id: I86aa92c7fae8d54ca603484b7e1746c126b0bddb
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
A RunWorker can in theory (and will in practice) support several
run modes. Also, it has turned out to be beneficial to specify
restrictions on a fine grained level, so re-use the idea from
the RunConfigurationFactory etc. constraints setup here.
Creation of RunWorkerFactories can be made protected at some time.
Change-Id: I9e2a84abfd7377c5bf0bbe84e0c7940b1317dc10
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
... to the plugins providing them.
To allow this being done one-by-one in the plugins, allow both
central and per-plugin ownership, and clean up the central instances
centrally. This step will be removed again once the transition
is complete.
Change-Id: Ica7786012e05ab83a0784448f2f8b3b781fe2167
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This paddles back a bit on the RunWorker creation setup mainly
to get a more flexible setup when it comes to share RunWorkers
between different setups.
Change-Id: I263742cb1df3689f133a2f6f948ed59a2a52d383
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
In remote setups without proper run configuration (e.g. attach
using the menu) there was no device available. In some situation
there's access to a kit, though, containing the right device.
Use it.
Task-number: QTCREATORBUG-20331
Change-Id: I54523f71fc10c9959901f36f3d62872d139279e5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Move some commonly used functions to the base,
The plan is to identify aspects by Id instead of type more often,
so avoid casts proactively.
Change-Id: I1b94b858a4491a0e31cedc788ded643a82242b2a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Names are easier to follow than positions in long argument lists.
Change-Id: Ia0ace9d864a1100e649f6725e7de338ab2653d05
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
As convenience function, and use it in some places.
Change-Id: I02e49f2cdc301bbf1261836032d3fa3a5b188446
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Any SettingsAspect that doesn't refer to the global settings has a
specific RunConfiguration it is about. This can be very handy to know
when constructing the actual settings. Right now there is no way to find
out about it.
Drop the clone() and create() methods. They weren't used anywhere and a
proper implementation should take care of the runConfiguration member.
Change-Id: Ie505a9b19707f8a1b6bf9cae73513cd3c30d0bca
Reviewed-by: hjk <hjk@qt.io>
The parent widget is always given by the layout, no need to pass
it as separate parameter.
Change-Id: I9e7ed3a89eb63b78a549471d839060131737ff78
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
