| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
...and print a warning with some user hint inside the application
output instead.
Drive-by fix: silence a soft assert in case of a failed start of
callgrind.
Fixes: QTCREATORBUG-28988
Change-Id: I4fd0253e1f18489031e2f6cfa276c4df5ea4483a
Reviewed-by: hjk <hjk@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
DebuggerEngine::appendMessageRequested specifies if a newline
should be added, but RunWorker::appendMessage did not use that
information.
Fixes: QTCREATORBUG-29098
Change-Id: I5ab1e489f691038fe1d9ea4a4d4b04429e403e0d
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
|
|
|
|
|
|
|
| |
This is the default behavior so no need to set it explicitly.
Change-Id: I7248a7a3890fa7fd947b8e42fccc70383d46ca3a
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
|
|
|
|
|
|
|
|
|
| |
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
|
|
|
|
|
| |
Change-Id: I77b27462d88079699e620ef459f951846c15c3e2
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
|
|
|
|
|
| |
Change-Id: I779f97a658b55f3c79111df1946b8d72863ce513
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
|
|
|
|
|
|
|
|
| |
The device can now be determined from the debuggee's file path.
Change-Id: I2b24d6e325f74826a644d02a9e418576c4e9b436
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
|
|
|
|
|
|
|
|
| |
It's static 1:1 nowadays.
Change-Id: I0bdc62bda4aade6753b04c42d95fbbdf70c37386
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
|
|
|
|
|
| |
Change-Id: Ia714a5a322ae56b07360871f584ec6f9f1babb5b
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
|
|
|
|
|
|
|
| |
A convienience function that leads to an interface that's "too stiff".
Change-Id: Ide2e5fd991707d08690e7e384e9048a30e0828f4
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
|
|
|
|
|
| |
Change-Id: Ib768e02033267d07278b7279a8172d237ebaa59d
Reviewed-by: Jarek Kobus <jaroslaw.kobus@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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to QT_RESTRICTED_CAST_FROM_ASCII to avoid the need for
decorations in user code.
At the same time, drop some convenience constructors and functions
in CommandLine and Icon essentially serving the same purpose.
Change-Id: Ida4e5ac19c2da0a4298a97b2a8e1511d56bbb79d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
|
|
|
|
|
| |
Change-Id: Id965f1f9047dcbc3ea5c9ddaa550d12668cf8ae6
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
|
|
|
|
| |
Change-Id: I2fbf8244a05ffb1b642843c6471f92e2b154cf8a
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
|
|
|
|
|
| |
Fixes: QTCREATORBUG-18693
Change-Id: Ibb968dcd82b118340a45329b4a14b28d85700661
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is usually used in a wrong or at least misleading way.
Replace most of the usages by newly introduced GeneralMessageFormat
as most of the replaced usages just print to General Messages and
using any of the existing formats would change the layout of the
text. Except for some special debug output inside the valgrind plugin
that can use one of the existing formats which also makes it easier
to spot them and the runners which print QC internal output.
Task-number: QTCREATORBUG-24560
Change-Id: I824dc4250b2f3e4656bab8676b45c98e3407d59c
Reviewed-by: Christian Kandeler <christian.kandeler@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>
|
|
|
|
|
|
| |
Change-Id: Idb7e119b5b0b483ce91efeb21fb415b654cfed4f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... taking a QString for the executable.
This weakens the very explicit QString -> FileName conversion via the
named constructors for the special case of constructing a CommandLine.
I think that's worthwhile here, as it reduces the noise on the caller
site under circumstance where the nature of the thing is obvious.
Change-Id: I27b4a73639728893d053b2e7ba65cb745f0ffe83
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
|
|
|
|
| |
Change-Id: I54d03ccda62121055509fd24c5c98a13f7605964
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
|
|
|
|
| |
Change-Id: I584bc18aa19a4c9886af7b13e95052dfd4350b34
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
|
|
|
|
|
|
|
|
| |
Bring it more in line with the standard pattern.
Plus some cosmetics.
Change-Id: I2297c4e72892db386c50ece7dc64bdc89f0d9010
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
|
|
|
|
| |
Change-Id: I30e8f27d4090576d38fe8a778d7fa508ac26cbfa
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>
|
|
|
|
|
|
|
| |
modernize-*
Change-Id: I6db60dce78cf2575e36caa597b1f095adba34fd9
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
|
|
|
|
|
| |
Change-Id: If93ca890ab6d023ab786a5153f50a1dfa03764de
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>
|
|
|
|
|
|
|
|
|
| |
... 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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Change-Id: I2cc5e966be44cb65f9dda5e55c38538badd78130
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
|
|
|
|
|
|
|
|
| |
The values are not "unknown errors", but known to be exit codes of
the debuggee.
Change-Id: Icc5e99d463269f1f167ab7b49b78b92c2e4c6b65
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of a blunt delete() RunControl::initiateFinish() is triggered
by the closing of the application output instead. The rampdown process
is basically the same as stop() now, except for the other success
signal (new finished()) and the final self-destruction of the
runcontrol.
stop() itself triggers initiateStop() on all running workers in
parallel (before it was in the order of start). This gives
downstream complex worker combinations the flexibility to use any
order it wants by ignoring stop() on 'uninteresting' workers,
and centralizing rampdown e.g. in the main worker. That setup should
be rare in practice, but seems needed in some profiler cases.
Change-Id: I986a152a663754206709ed4df0d4568847afad17
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
A RunControl is re-runnable if all its workers are,
a RunWorker is re-runnable if it's Stopped and unless it
says otherwise.
Also ensure SimpleTargetRunner only reportStop() once
per run and make process error message re-usable.
Change-Id: I73f5fb724d3026ceb81d5e32a3a71b4814b2bca9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
|
|
|
|
|
|
| |
Remote CallGrind is still dysfunctional.
Change-Id: Ib9ab537dc068c94c7e61ac48b1a4b9d655ccb60f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's only used internally as one-time communication between
worker and the *Tool singleton that handles toolbar button
states.
We basically start immediately after creation of the worker, so
any pre-start tool bar specific operations can be done at
RunWorker creation time.
Medium term, the runworker should proably steer "their" buttons
more directly.
Change-Id: Id6df703746ece5eebc23507739cd2a92ec55d11d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
|
|
|
|
|
|
| |
... instead of having one in each derived class.
Change-Id: Icd121ce46b1d161bd2d59eaeaad8363528dc3c23
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
... and QmlProfilerRunner::Configuaration by PE::UrlConnection,
and call it 'serverUrl' on the user side.
That's the only variant we ever had and avoids "translations"
between three structures that are essential the same.
Change-Id: I33386b2b8d2a7985ff934f6f8f840de0831bf9c1
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
|\
| |
| |
| | |
Change-Id: I56004e3ec9dc9d92d33bdae438c4f7e069eccc45
|
| |
| |
| |
| |
| |
| |
| | |
Task-number: QTCREATORBUG-18254
Change-Id: I49a20edafa1d241c83a301ce9652a6fb839bed93
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: hjk <hjk@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
Also provide a name for the workers.
Change-Id: I323c498db1eeb8225170aae080fdf084aa53e14a
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This increases re-usability of activities like 'port gathering',
and makes their use less dependent on actual device implementations.
Change-Id: I017cb74874f2b38c487ba2d03906a675d5618647
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Forward all tool and target activities to run control, and initiate
further state transitions (only) from there. Also, make sure
tool/target's on finished() triggered on all finishing code paths.
After that, the base state handling is sufficient to handle remote linux
running and debugging.
Change-Id: I0150ef249c9ad0b7b8ac7192be6dc860c9ca8fc5
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
| |
| |
| |
| | |
Change-Id: I1167fdc147600c36149c13731d0680b858acf4fb
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Removes one reason to derive from base RunControls (specifically
ValgrindRunControl).
Change-Id: I81e32a49ef30e79ee7e7b53a54021eaaba43453a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
|
| |
| |
| |
| |
| |
| |
| | |
That's a good first approximation and often enough all that is needed.
Change-Id: If54cdb0e98cda94bc4a4ef24fcc12c78018c4dbe
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The change is "conceptually wrong", the AnalyzerRunControl derived
classes' functionality should be provided by ToolRunners based classes
encapsulating/"being" the current Analyzer*Runner classes.
However, the AnalyzerRunControl is only three (empty even) virtual
functions, but a big obstacle in merging attempt due to a lot of
mechanical followup changes in downstream users.
The current construction mechanism of analyzer run controls is actually
two different mechanisms (locally direct RunControlFactories, and a
"generic" createAnalyzerRunControl wrapper for remote cases). The generic
createAnalyzerRunControl makes it difficult to migrated them one-by-one,
due to the various downstream users.
So instead of merging the per-analyzer two uses directly reduce
the "indirection" distance by removing the AnalyzerRunControl
intermediate layer. After that the createAnalyzerRunControl mechanism
can be dissolved by using normal RunControlFactories also for
the remote cases. After that, porting to ToolRunner, and combining
with ther local equivalent can be done one by one.
Change-Id: I0ddace33fcce210cf3a547ac5bb23b3d85013934
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces a mini-state-"machine" to handle RunControl states
Intialized->[Starting->Running->Stopping->Stopped->]*->Finished.
Needing time between trying to start and getting feedback is nowadays
the normal setup for all remote targets as well as for most local tools.
Making that the default for all runs simplifies the code and provides an
opportunity to (a) fix some currently wrong reports of "stopped
immediately" and (b) to remove target-specific (WinRT) or tool-specific
(Valgrind, GammaRay) state members doing essentially the same.
Change-Id: I7f52fee41144188ee8389e922fdc265f8c0a6459
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
|