The TaskTree class is responsible for running async task tree
structure defined in a declarative way.
Change-Id: Ieaf706c7d2efdc8b431a17b2db8b28bf4b7c38e5
Reviewed-by: hjk <hjk@qt.io>
Whenever user calls terminate(), kill() or stop() this
sets the m_canceledByUser flag to true inside result().
Change-Id: Ic99642762868fd0a28193caa8ea05e165cb2a277
Reviewed-by: hjk <hjk@qt.io>
This is extracted separate object out of VcsCommand.
It's responsible for showing progress of the running
process. It's able to cancel the running process
automatically after pressing a small 'x' indicator on
progress panel. In this case the QtcProcess::stop()
method is being called.
Change-Id: I9fa94fd047638f76909356ae4023852349be3a06
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This is alternative to setStd[Out/Err](Line)Callback()
methods. In this way there may be many clients connected
to textOnStandard[Output/Error]() signals. This should
also simplify handling the lifetime of user callback.
Change-Id: If82baa1f3f9c432ed431926619b9bbf11d770a84
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace.
Task-number: QTBUG-99313
Change-Id: I88edd91395849574436299b8badda21bb93bea39
Reviewed-by: hjk <hjk@qt.io>
Reuse starting() signal for doing initial debug printout.
Keep dynamic properties in QtcProcessPrivate only, so
no need for passing it.
Change-Id: I170ea96c37e1b9904037851799316de629bfb86e
Reviewed-by: hjk <hjk@qt.io>
The keepRawData field may be false only after calling
setStdErrLineCallback(). In all current usages (7 places)
we don't call stdErr() nor cleanedStdErr().
VcsCommand was using setStdErrCallback() so that did not
change the keepRawData to false.
It looks like currently it should be safe to fix this assert.
Amends 4000819262
Change-Id: I9f8627166d194579c5a0fe13d241ff37aecac47c
Reviewed-by: hjk <hjk@qt.io>
And instead of qgetenv.
Takes Qt Creator's setting at "Environment > System > Environment" into
account, which makes it easier on some platforms to set them (e.g.
macOS), can be configured differently in different settings paths, and
potentially can be changed at runtime (depending on usage).
Change-Id: I50e457bab2d3495e5c69676fe1a0257a5fea3e52
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@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>
This replaces the ProcessInterface::waitFor...() methods.
It's not obligatory to provide this interface when
implementing ProcessInterface subclass. In this case
generic blocking implementation will be used.
The generic implementation usually isn't as efficient as
the custom one, however, for some sophisticated implementations
of process interface, like e.g. SshProcessInterface, providing
custom implementation is really difficult and error prone.
That's why we try to keep a balance: we provide two custom
implementations for QProcessImpl and for ProcessLauncherImpl,
as they are relatively easy to implement, and rely on
generic implementation for others.
Change-Id: Ifc8bd354479ec67b2e8f74f1510f8de8883e9b94
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Before we were installing the timer inside the process
interface handler. The issue was that when the handler was
moved into another thread, the timer was restarted (that's
what happens with all timers when they are moved into another
thread).
The fix is to keep the timer inside the caller thread and
detect inside waitForSignal() whether a timer was started.
In case the remaining time for kill timer is less than
a timeout for waitForSignal, we split the waiting into two
parts and execute kill() in meantime.
Change-Id: I2c18805593fe2f73d816cce40dbb45bf58a50715
Reviewed-by: hjk <hjk@qt.io>
Rename it into ProcessSignalType. It's going to be
used in new interface.
Change-Id: Ifbab8bbb601f14ecbf65d940e524c558d5f1d7a1
Reviewed-by: hjk <hjk@qt.io>
Add a setter and getter for reaper timeout. This makes it
possible to customize the timeout for the reaper after which it
should call kill() when previous terminate() was unsuccessful.
This setting is also used for QtcProcess::stop().
Change-Id: I653a3ad107ae4173bb8254c85cfc07886bf6a9c6
Reviewed-by: hjk <hjk@qt.io>
This method works like close() with the difference that
after calling stop() we are still going to receive
signals from QtcProcess, especially done() signal.
This method isn't blocking, so a calling it is fast.
Just after calling this method QtcProcess is still
in the same state and done() signal should be delivered
asynchronously. It's safe to call waitForFinished() after
calling stop() with the desired timeout.
Calling stop() in a row with waitForFinished() is a good
substitute for stopProcess().
Change-Id: I1df55beb7f89c9b73203c9ba4bc276a4060600a5
Reviewed-by: hjk <hjk@qt.io>
More descriptive, and later implementable without full expansion.
Change-Id: Ic3b17ea0b07273f292827a7b63e7695b4bd1cf23
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Fix it also for general waitForSignal() implementation.
Amends fc2f3983bc
Task-number: QTCREATORBUG-27578
Change-Id: Ifb9ebbd5c3fa2c900bae924aefccb713983b1697
Reviewed-by: hjk <hjk@qt.io>
Make it behave more like QProcess::kill().
Before, when QtcProcess::kill() has been called,
the process launcher was putting the process into the
reaper and notified the QtcProcess that it was already killed,
while in fact it could still be alive for a while since it
was in reaper's hands. The current fix makes the behavior
similar to what QProcess does when calling kill(). So now,
in case of a call to kill() the process isn't put into the reaper yet,
so it has a chance to report back the finished signal when the
process was really stopped.
We still use the old behavior of putting the running process
into the reaper in case of a call to QtcProcess::close() and
when d'tor of QtcProcess was called. We don't report back the
confirmation about putting the process into the reaper, since
close() is always called from ProcessLauncherImpl d'tor, so
there is no one to receive this confirmation anyway.
Change-Id: I665e7c8fb1a391dda30c86389259961e715926d6
Reviewed-by: hjk <hjk@qt.io>
Round 2 - focus on sources.
For classes with initial in range [I-Z].
Try to keep the same separators between different kind of headers.
Change-Id: I8a7ab99bab8120ee72cda6433ee3dc6f260a4d76
Reviewed-by: hjk <hjk@qt.io>
Round 1 - focus on headers.
For classes with initial in range [P-R].
Try to keep the same separators between different kind of headers.
Change-Id: I01fb80b93164a7fe4c0bd2cd8f9e4f27523efefa
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
It's a result of a team work consisting of yellow triangle and me.
Change-Id: I8b4812766da70e0785ae71bf0cb71357379e2514
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
process_ctrlc_stub doesn't generate a Ctrl+C event sent via
GenerateConsoleCtrlEvent for the child process to terminate.
So the Debug restriction to workaround QTCREATORBUG-11995 is
no longer needed.
Change-Id: Iafc8b51bce17432c80b0be0c4084978abc1c909f
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
... and drop QtcProcess::removeEnvironment()
This shifts the meaning of the unqualified QtcProcess::environment()
to always refer to (possibly remote) "main" process this QtcProcess
wraps. The controlEnvironment is now referring to secondary helper
processes (if any...) typically(?) running on the host system.
This helps to avoid local/remote distinctions in some places.
Change-Id: Ib7cd15dd226617484b5358acd7deaed29e751883
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Currently, as a result of many refactorings, the QtcProcess
is designed so that if you want to customize the behavior
you should implement custom ProcessInterface subclass.
Adding virtual methods directly to QtcProcess caused tons of
unpredicted side effects and nasty bugs, which were hard to
track and hard to fix, as provided fixes were usually fixing
particular case while introducing regressions in not related
code paths.
Consider also aggregating QtcProcess object instead of
deriving from it when some additional methods are required.
This patch removes the last virtual methods from QtcProcess API
and makes the class final in order to prevent from adding
any new virtual methods to this class in the future.
This commit message should make it clear that having subclasses
of QtcProcess is not a desired design. It's a post-mortem
conclusion. So: don't derive from QtcProcess - we mean it!
Change-Id: I1e43ed45be326b366422fd7db6e05ba48ea5fb98
Reviewed-by: hjk <hjk@qt.io>
