Make Environment a stack of changes that gets "expanded" to
a full environment before things are actively accessed.
Later this expansion should be done lazily if possible.
Task-number: QTCREATORBUG-28357
Change-Id: If1c7bfdb9f58b81e71c51ed87ee75d6964a47019
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Previously DesktopDevice::openTerminal used custom code to open a
terminal window. This patch changes it to use QtcProcess with
TerminalMode::On.
This also removes the need for "openTerminal.py" on macOS.
Change-Id: Iec978bdd19487ff8e59dcd88c35c2d01b0681022
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
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>
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>
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>
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>
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>
We store pointers to signal objects inside m_signals list,
so we can't easily merge the old ready read signal with
the new one, since when flushing the m_signals from the main thread
we are taking copy of m_signals, but this copy still holds
the pointers to the original objects, and using them outside
of locked mutex isn't safe.
The possible solution would be to store simple data structures
instead of signal objects allocated on heap. However, there is
not really much gain of merging the ready read signals, so we
get rid of it.
Task-number: QTCREATORBUG-27578
Change-Id: Idd19a6fc1ebb4ccab1e4e367cfeb3f2f02a35512
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
After changing the protocol so that error signal is no more
sent we need to flush the buffered Done signal when
awaiting for Started signal.
Change-Id: I274bfa375db05627348684f11be535d79c62b42b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Instead of holding the start packet on caller side when
launcher socket isn't ready yet, pass it into the launcher
socket and buffer it there until the socket becomes ready.
This simplifies starting the process considerably.
Get rid of CallerHandle::canWaitFor(), as this is already
checked by QtcProcess itself.
Get rid of LauncherHandle::m_waitingFor field and
LauncherInterface::isReady() method, as both are not used anymore.
Change-Id: Ida6f0629170647249e562028c3ea5db1830b8a0d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Restored the process channel mode members to ProcessSetupData and
StartProcessPacket and forward to the QProcess created in
LaunchSocketHandler. LaunchSocketHandler now avoids reading from stderr
for merged channels since it's guaranteed to not be available.
This avoids asserts in Qt 6.3.0 and warnings in Qt 6.3.1 while
preserving the original output order when an application has a mix of
stdout and stderr output.
Change-Id: I9f4541932cf9d8638b38658a5efea9cb5f1798f3
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Keep the setup data on stack instead on heap.
Task-number: QTCREATORBUG-27358
Change-Id: I0fffd525e2bd4f46533804e3b88fe5b330d02a91
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
And get rid of readyReadStandard[Output/Error]() signals.
Get rid of readAllStandard[Output/Error]() accessors, as
this data is passed with readyRead() signal.
Task-number: QTCREATORBUG-27358
Change-Id: I01341feba650e650761f97e90f83b6042c899251
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
And get rid of errorOccurred() and finished() signals.
Get rid of resultData() accessor, as this data is passed
with done() signal.
Task-number: QTCREATORBUG-27358
Change-Id: I677bbd174cceea6d8f5a989f961222c417992b60
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
ProcessLauncherImpl::terminate() was behaving the same as
ProcessLauncherImpl::kill() in case of process launcher
implementation - in both cases the launcher
immediately returned confirmation about receiving the
close request and was putting the corresponding
process into its reaper. However, the issue with this approach
is that we can't receive anymore any potential ready
read signal from the process being terminated after
a call to terminate().
The fix is to diverge the behavior of terminate()
and kill() of ProcessLauncherImpl. The behavior of kill()
remains the same, while terminate() just instructs the
process launcher to start termination without putting
the process into the reaper, yet.
Add a test that checks for any possible zombies.
We run the RecursiveBlockingProcess recursively. The most
nested process blocks. After a short wait we terminate
the outermost process. With this test we are trying to see
if terminating the middle process terminates also its
children and doesn't leave zombies.
Before we execute the test (and also by the end of this test)
we call Singleton::deleteAll() in order to ensure that reaping
of previously running processes has finished. We ensure the
number of running processtestapps is zero. Later, we ensure that
the leaf process was already started and the number of running
processtestapps equals the depth of recursion.
Fix apparent bug in getLocalProcessesUsingProc().
Change-Id: I7e2bc46ad5ca22f26620da86fbaf0fa00a7db3c3
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It should be useful when reimplementing ProcessInterface.
It replaces 4 virtual methods with just 1.
Task-number: QTCREATORBUG-27358
Change-Id: I2dafbfbc25f8f016ff2aa19c1a176335a4a7498c
Reviewed-by: hjk <hjk@qt.io>
It's internal method, not meant to be used outside.
It's only used in case of FailedToStart error.
Remove it also from ProcessInterface.
Leave it inside DefaultImpl and its subclasses only.
Remove m_errorString field from ProcessSetupData.
Change-Id: Ie605b95c2ff605ab1259045f1a5b16049207c1d3
Reviewed-by: hjk <hjk@qt.io>
Instead of relying QProcess to operate with MergedChannels, keep
the separate channels and merge inside QtcProcess.
Fixes: QTCREATORBUG-27196
Change-Id: I3039267fcd6d90f95f8212642e17049b87af1156
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Don't detect a call to QtcProcess::kill() from inside the
QtcProcess callback while awaiting inside QtcProcess::waitFor...().
That's not needed, since a call to kill() sends a stop message
to the process launcher, so we wait for confirmation
from process launcher instead. This may bring e.g. new
read data from the running process.
Fix a runBlockingStdOut() test so that when we write to the stdOut
from the running process we flush the unfinished line so that
it's not buffered inside the process.
Change-Id: I7944ac214d8cb9e10a71715a7ef8bfacab6df7c9
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
...instead of ensuring in many functions that m_setup isn't null.
This amends 36c49cd2ea and
solves the issue for other functions like processId(),
exitCode(), etc...
Amends 36c49cd2ea
Change-Id: I986f7b30e90e5825ae2bb57b4bc2aa14f56e401f
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
ProcessProxyInterface will be helpful when implementing
public subclasses of ProcessInterface, like
general ssh impl, linux specific impl, qnx specific, etc.
ProcessProxyInterface is sharing private data
between proxy and target.
Change-Id: I8350837bb5f770d6605b860b146604cba5e6b592
Reviewed-by: hjk <hjk@qt.io>
Drop it also from registerHandle() methods, as it wasn't
used there.
Change-Id: I34b72c38368b82f22d73314fe3cd429ed43cadbc
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Also simplify the wording of a message.
Task-number: QTCREATORBUG-27055
Change-Id: I29df31f8484d451d8d8d1869ca3a1b182072d2c1
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Don't pass writeData, as that's available through
ProcessSetupData.
Change-Id: Ic55b21c6a3338168ee251bcc1c57594f50c52d2f
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Use Utils::Environment for of environment.
Use Utils::FilePath for workingDirectory.
Change-Id: I6b717139f8ff7ddbd629fb22cf816b2303fb5e6a
Reviewed-by: hjk <hjk@qt.io>
In case the user called waitForReadyRead() and we have
received the finished signal instead (without receiving
readyRead signals in meantime), we should interrupt
the wait and return false, since there is no point to
wait for future readyRead signals from not running process.
Change-Id: Ib4a770aea6ed562a5bef197eaa51b20c146842f0
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Sometimes after creating QtcProcess we move it into a different
thread. In this case we should move all the children, too.
Without parent-child relation all the children will stay in the
old thread.
Change-Id: Ibde44d6153092a155dd2d200a7116a046910dddc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Remove the process in process launcher after error has appeared.
Remove unneeded stopStopProcedure as we are disconnecting from
process' signals inside removeProcess().
In order to behave as much similar to what QProcess does,
provide a test that:
- ensures the FailedToStart error is synchronously emitted
when waitForStarted is being executed
- ensures that process state is reset to NotRunning after
FailedToStart error
- 2nd call to start/waitForStarted doesn't block on
waitForStarted
Change-Id: I139354421d037739f1cc1a2685b66f1e5b6170c8
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
