Use existing error() signal instead.
Implement errorString() and processError() in non-local case.
Change-Id: Ibdd6cec19ffa5efa0dad330515988da80e86e35b
Reviewed-by: hjk <hjk@qt.io>
Use existing processStarted() signal instead.
Replace isRemoteRunning() with isLocal().
Change-Id: I58d0204888116c00e793fa43f969707013db06eb
Reviewed-by: hjk <hjk@qt.io>
Use existing appendMessage() for this purpose either with
StdErrFormat for remoteStderr() or with StdOutFormat for remoteStdout().
In case when device process is used in ApplicationLauncher
no appendMessage() was emitted so far with StdErrFormat or StdOutFormat.
Change-Id: I2f6603aaf28113fea2a8bb6bd1738320cc39be75
Reviewed-by: hjk <hjk@qt.io>
Use existing appendMessage() for this purpose with NormalMessageFormat.
In case when device process is used in ApplicationLauncher
no appendMessage() was emitted so far.
Change-Id: I96041ad19fe16066ea31d92f52253e0aa864f96d
Reviewed-by: hjk <hjk@qt.io>
Before the m_startFailure flag was used to detect the case
when the process failed to start because of wrong filename.
As this flag was set on any possible error we have always
detected the wrong filename case. Replace this flag with a
new enum describing various start failures.
Don't report again the crashed message. Check if we have already
reported the stop and we don't report it again. The
processExited() handler is being called twice: directly from
localGuiProcessError() and through the delayed localProcessDone().
Fixes: QTCREATORBUG-26467
Change-Id: I3cc6aa0c0b702256cefd77ba95793cd31e82ae10
Reviewed-by: hjk <hjk@qt.io>
In some cases (e.g. "Attach to running application") there is no
proper RunConfiguration, so fall back to Target or Kit.
Amends e78f456083
Change-Id: I0093d5f573fc259fd2a72bbc1aaa22dcb8adbaee
Reviewed-by: David Schulz <david.schulz@qt.io>
In the light of docker support it would be nice to have a way
to tell existing RunWorkerFactories that they also work for
docker, or generally to increase the scope to which they apply
after construction time.
Small con: Some more boiler plate,
Small pros: Setup using the new method looks similar to what we use
in the other factories, and the Factories types are recognizable
when debugging.
Change-Id: Idb1757f519e7151b835326aa8b98aeaa4a372cc4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
I find the std::bind version much harder to debug.
Change-Id: I0badb4c29097a5432b110a815cb2206477091d98
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For local run and GDB debug, with or without terminal.
Task-number: QTCREATORBUG-2831
Task-number: QTCREATORBUG-25330
Change-Id: I9b5d2156bcffea4f358474ecdbcad580a4419917
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... to centrally set SUDO_ASKPASS unless present.
To be used for 'Run as root'
Change-Id: I85bac939e6a7fba0b2299fd17edfe73577bfa5ad
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Classes involved are BaseAspect and some derived classes,
LayoutBuilder and VariableChooser.
This is mostly mechanical, with various include/using changes
to make it compile.
Change-Id: I624a457f3555f102e541c4c71e33a9423af32250
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... for the app output window.
Fixes: QTCREATORBUG-24560
Change-Id: I199d7b16f445db498027094792c6cf344d920a88
Reviewed-by: André Hartmann <aha_1980@gmx.de>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
(cherry picked from commit 430a33dcd9)
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
There are very few reasons to use mainWindow() directly.
Especially for modal dialogs, using dialogParent() is important, since
that guarantees the stacking order in case of other dialogs currently
being open.
Change-Id: I7ad2c23c5034b43195eb35cfe405932a7ea003e6
Reviewed-by: hjk <hjk@qt.io>
They can now be created independently of any toolchains, and we expose
them in the build and run configurations, so that users can easily get
tasks for output that comes from custom tools or is otherwise specific
to the user's environment.
Fixes: QTCREATORBUG-23993
Change-Id: I405753b9b68508ffe5deb4fcac08d6b213c7554d
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: hjk <hjk@qt.io>
... when creating a run control for a Qt project. Now tasks will appear
in the issues pane for QtTest application output in the app output pane.
Task-number: QTCREATORBUG-22665
Change-Id: I2674f3d4f9aabc0a4db4178dcd5495b822f14022
Reviewed-by: hjk <hjk@qt.io>
An OutputFormatter takes some string and prints it into a text edit.
In addition, it can ask any number of registered OutputLineParsers
whether they think any special formatting should be applied to the
current line.
This mechanism is now properly modeled by our class design, rather than
being hidden in a monolithic class where everything had the same type,
no matter what its purpose was.
Prospective contributors can now simply be pointed to the
OutputLineParser class and will see at one glance what they have to do.
Change-Id: I9844499f062c94fb038ce73fd6f26576910148c2
Reviewed-by: hjk <hjk@qt.io>
Introduce an aggregating output formatter that forwards its input to a
sub-formatter that feels responsible for it, or otherwise lets the base
class handle it.
Our output panes now use such an aggregating formatter.
In particular, this means that in the future, we won't have to stuff all
run control output formatting into the Qt output formatter anymore.
Change-Id: I5498f200a61db10ccff3ec8974c6825da7f7072d
Reviewed-by: hjk <hjk@qt.io>
Presumably, they were intended for output that shouldn't get an
automatic newline, but if there ever was such a thing as automatic
newlines, it must have evaporated over time. All users of
OutputFormatter provide a newline if they want one.
Change-Id: Ibd219b7305fd503ce075d6f77930d2b538d5e2e8
Reviewed-by: hjk <hjk@qt.io>
... by MacroExpanders in Build and RunConfiguration. Deploy didn't
use its own, BuildStep always composed an empty expander with
the BuildConfiguration's, uses now the BuildConfiguration's expander
directly.
Change-Id: I9de51bfc32aeb3d73f4974175e42a37807e49ac1
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... or Target.
This patch moves build system from conceptually "one per project"
to "one per target (i.e. per project-and-kit)" or "per
BuildConfigurations" for targets where the builds differ
significantly.
Building requires usually items from the kit (Qt version, compiler,
...) so a target-agnostic build is practically almost always wrong.
Moving the build system to the target also has the potential
to solve issues caused by switching targets while parsing, that
used Project::activeTarget() regularly, with potentially different
results before and after the switch.
This patch might create performance/size regressions when several
targets are set up per project as the build system implementation's
internal data are duplicated in this case.
The idea is to fix that by sharing per-project pieces again in
the project implementation once these problems occur.
Change-Id: I87f640ce418b93175b5029124eaa55f3b8721dca
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... on runcontrol creation to prevent later access. Adapt some users.
There are more to come.
Change-Id: I2a3fe5eea0ada4eff7d08b79a6f49694e6962c8a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This spares us the typical r = runnable(); modify(r); setRunnable(r)
roundtrip and the m_runnable storage that might or might not
be the same as runControl->runnable. Similar for m_device.
Change-Id: I8300260dd8dd7cd395e40bcd3d2ae45089085008
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This unifies the remaining paths of RunWorker creation to always
use RunWorkerFactories in the plugin pimpls.
There were, and are, still effectively three basic kinds of workers:
- "toplevel" tools corresponding to the run modes, that are often all
that's used for local runs and directly started via the fat buttons
or e.g. entries in the analyze menu, with factories already previously
located in the plugin pimpls
- core "tool helpers", providing tool specific functionality typically
used in conjunction with a remote device specific run mechanism,
set up via RunControl::registerWorkerCreator
- target/device specific runhelper like port gatherers contructed e.g.
via *Device::workerCreator(Core::Id id)
Worse, these categories are partially overlapping, so it was not
clear how a "clean" setup would look like, instead some ad-hoc cobbling
"to make it work" happened.
In some cases, the runMode id was used throughout the whole ensemble
of run workers for a given run, and which worker exactly was created
depended on which of the mechanism above was used in which order.
With the new central setup, the top-level runmodes remain, but the
second kind gets new ids, so the implicit dependencies on order
of setup mechanism are avoided.
This also helps in the cases where there was previously unclarity of where
and how to set up worker factories: It's always and only the plugin
pimpl now.
Change-Id: Icd9a08e2d53e19abe8b21fe546f469fae353a69f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Essentially walking the RunModes x RunConfigs x Devices cubes.
Information is just the factory pointer, or null, some name would be
nicer, but for now it turned out to be sufficient.
Change-Id: Ifdf92b2353cb5c0346ee4566beb7d78a00645aed
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Essentially following the scheme used for the various project
configurations. This makes it possible to construct OutputFormatters
by Id only, potentially reducing hard plugin dependencies and
opening the road to have several output formatters per
RunConfiguration/Outputpane/...
Change-Id: I4b5fb6fb6be8b0d9a0859f178bb0effc3398b09e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This combines two of the previous three paths to create run workers,
and refers to RunConfigurations by id, not by type where possible
to decrease coupling between the classes.
Only allow "type of run configuration" and "type of device"
as the only possible kind of restriction and require a uniform
RunWorker constructor signature.
Adapt user code to fit that pattern.
Change-Id: I5a6d49c9a144785fd0235d7586f244b56f67b366
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... by two accessors to the only used field. General idea here
is to make the presence of a RunConfiguration in a RunControl
less prominent to be able to remove it at some time completely,
as the configuration's data might change while the control is
running.
Change-Id: I752540fadd135d6904fc9bf4e3506be074b0c003
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For some reason, Q_UNUSED includes already a semicolon, adding one
on the user side creates an additional empty statement.
Change-Id: I9c5e8fac381345a60792cb75e2938fd53958d3b0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
We regularly pass around strings or filenames or pairs of strings
or filenames and stringlist etc the in the end will be used
as a kind of "command line", with quite a bit of ad-hoc user
code and QtcProcess::addArg etc to set them up and manipulate them.
Let's have a class for that concept.
Change-Id: I288ab939d853b32c717135a65242c584c2beab50
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... in RunWorkerFactory. The semantics is the same as in the other
{RunConfiguration,BuildConfiguration,...}Factory::addSupportedFoo
cases: As long as none is specified, there's no constraint, if
there are any, it's a whitelist.
Change-Id: Ia05afd9afe6886e4bacc58ac786f2548f03e5ca8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
