Most inclusions of idevice.h inside other headers are
required just because of IDevice::Ptr or IDevice::ConstPtr
was used there. Unfortunately, since these "using"
are defined inside a IDevice class, we just can't
forward declare IDevice::Ptr nor IDevice::ConstPtr.
Instead, create a separate header that defines
IDevicePtr and IDeviceConstPtr while having IDevice
forward declared. Redefine IDevice::Ptr/ConstPtr
inside IDevice to use IDevicePtr/IDeviceConstPtr.
Now, instead of forward declaring a IDevice::Ptr
it's sufficient to include the idevicefwd.h.
This drops the number of files being recompiled
after touching idevice.h from ~770 to ~210.
Change-Id: Ib6f2982aa0761fb4cd6593badb9c3c0c527ea535
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
The aspects are now responsible for defining what data needs
to be copied and also to provide a suitable interface (kind
of source-compatible to direct use) for access.
The important change here is that RunControl::aspect(...) doesn't
need to access RunControl::runConfiguration() in fully aspectified
RunConfigurations anymore. In not-fully aspectified the runConfig
access is moved to the user code to make the problem visible there.
Long term, aspectification should be finished.
As an additional benefit, the resolving of macros etc can
now be done at the correct time.
Change-Id: I690d9f8f696ce9b4efd42082ba3f81b514efcb77
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Brokken by the f1e973de79.
We must pass local `runnable` instead of runControl()->runnable(),
otherwise device member will be nullptr that breaks all non-Desktop run
configurations, like RemoteLinux one.
Change-Id: I0499008aee14cb3bbcc3e1ebda71c50533b6502e
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Make the API more similar to QtcProcess API.
Rename:
processStarted() -> started()
error() -> errorOccurred()
processError() -> error()
Change-Id: I86d650d55a643f5999fc91e56b985f699e2d7245
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Use device set inside passed runnable instead.
Grep for all usages of RunControl::start().
If passed device wasn't nullptr, set this device
inside passed runnable. Otherwise ensure that
passed runnable contains device set to nullptr.
Change-Id: I06fd42a16246fa9fedd81eeb47481a217f887cb0
Reviewed-by: hjk <hjk@qt.io>
Treat DesktopDevice and all derived devices as local
in application launcher.
Change-Id: Ie1a025c03f1c96158c67e0c900f89e33ec7c4663
Reviewed-by: hjk <hjk@qt.io>
Take the device from runnable passed in setRunnable().
If the intention is to run locally, set the device
to nullptr inside runnable. Otherwise we don't run locally.
Follows 47957de2dc
Change-Id: I5b381bb499cf76e469c844ac7474ce2f60761cef
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
And rename it to finished().
Maps better to what QtcProcess uses.
Change-Id: Ibfa018549f436b27638a791c0b4937c4459c9452
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
There's traditionally an odd duplication of the runnable.device
and the passed device here. Start disentangling things.
Change-Id: I1cc1628c99cea04d761fc4d8dd0cb232127ce055
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
The warning was issued when re-running from output pane.
According to RunControlState class description
the transition from Stopped to Starting is a valid one.
Change-Id: I264630dc1c23c359ff4e9d4a7a292b9b0c55ec5a
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
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>
