Since e755094480 we have a global option
in Qt Creator to set the (base) environment for any tools run by Qt
Creator. So it is expected that any tool actually uses
Environment::systemEnvironment() as a base, which is the system
environment modified by the global option.
QtcProcess already had a fallback to Environment::systemEnvironment for
resolving environment variables in Qt Creator macros in the command
line. Also use it as a fallback for the actual environment for the
process.
Latest occurrence where the global environment setting was ignored was
for starting language servers by our LSP client.
Change-Id: Id1a4141326d8ef3239b37d7f3daf21928605ca92
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Fix a race condition in the following scenario:
QtcProcess proc(...)
...
proc.start();
proc.waitForStarted();
if (!proc.waitForFinished()) {
// handle failure here
return;
}
// handle success
Move all the data into the caller's handle
and manage the QtcProcess state only from
inside caller's thread. This eliminates race
conditions when state changed from inside launcher's
thread while the caller's thread isn't notified
immediately.
For example: currently, when the launcher's thread receives
finished signal it doesn't change the process state
immediately, but posts a finished signal to be
dispatched in the caller's thread. When the caller's
thread dispatches the posted signal (inside flush() method)
it changes its state and posts the finished signal to the
outside world.
Don't flush all signals from waitForStarted(). Flush
only started signal in this case.
Change-Id: Ia39c4021bf43b8d0e8fcda789c367c096bfd032c
Reviewed-by: hjk <hjk@qt.io>
A convenience wrapper around QProcess::startDetached().
Change-Id: If4228e8405ad4d5e172930593a6f670874211767
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Add some developer comments explaining which method
is designed to be called from a certain thread.
Add also some comments about in which thread
certain QObjects live in.
Change-Id: I38b10216cc29f8a86fd784e588e913407f0fb776
Reviewed-by: hjk <hjk@qt.io>
All the uses of setStd{Out,Err}Callback in the codebase call proc.stdOut/
stdErr after the execution.
This triggered a soft assertion that was apparently not noticed so far.
It broke for example prompt for conflict resolution on Git pull/rebase.
Change-Id: Ib4b8301f1f50b2b66f02fc4dc6c14d93f895ea33
Reviewed-by: hjk <hjk@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>
Use QTC_USE_QPROCESS env var to switch back to the original
implementation based on direct use of QProcess. By default
a new implementation employing process launcher will be used.
Change-Id: I75c3efb579e26de377fc785404f1e2a08367d994
Reviewed-by: hjk <hjk@qt.io>
The previous tighter check is actually good theoretically, but currently
ShellCommand::runFullySynchronous triggers it and disentangling there
is not trivial. So weaken it a bit for now to not annoy users.
Change-Id: Ifc6b5713b398db0af0f604834c37ff361c2a1ed3
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Remove setCreateProcessArgumentModifier() from the ProcessInterface
API and replace it with belowNormalPriority flag.
Change-Id: I6bcb92e56c3a68af7fa3e3a1c8b8eb13e3a2e5a7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
This patch needs to be applied together with the parent change.
There are 3 basic cases:
1. The user doesn't write anything to the write channel:
You don't need to call closeWriteChannel manually anymore.
By default the QtcProcess you create is in ProcessMode::Reader mode.
Internally it opens the process in ReadOnly mode and
closes the write channel just after starting.
2. The user writes some initial data (after being started)
and then closes the write channel:
All what is needed now it to set the write data
(QtcProcess::setWriteData) before calling start.
You also use the default ProcessMode::Reader mode.
Internally it opens the process in ReadWrite mode
and writes the writeData asynchonously when the process
already started. After writing the data it closes the
write channel automatically.
3. The user writes the data also after calling start.
All you need now is to create a process with
ProcessMode::Writer mode. In this mode the write
channel is not closed.
Internally it opens the process in ReadWrite mode
as some writers also read the data from the process.
All the code base is adapted here to the above rules.
Change-Id: Id103019d1d71a3012fd1eade226fe96b9aaa48c2
Reviewed-by: hjk <hjk@qt.io>
Don't base process token on instance pointer,
as it may happen that the recreated instance may
get the same token again (it happens often when invoking
a function that recreates QtcProcess in sequence).
The consequence may be that on the project launcher side
we may reuse the old process (with possibly broken state)
instead of creating a new one.
Change-Id: I8274691f88ae0eefe008746d944a26f29979bf72
Reviewed-by: hjk <hjk@qt.io>
The internal handling of output gets in the way when trying
to read output from a process synchronously.
Make usage of the internal one instead of relying on the
original output handling.
Fixes: QTCREATORBUG-25958
Change-Id: Ie96b5e8d17799a613ff15a52a23a8bdc31cb2939
Reviewed-by: hjk <hjk@qt.io>
Provide way to clean QtcProcess environment which is needed as
e.g. toolchains, build tools, and debugger otherwise run
inside a wrong environment when using docker exec for the
respective process calls.
Change-Id: Ia6de1c90f2134fce260d293a2f6937ab3cfca2ce
Reviewed-by: hjk <hjk@qt.io>
So that this doesn't only apply to runBlocking()
Change-Id: I6ef7c72e13a5e214c7476ede942662a9893c843c
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Move launcher process into a separate thread.
Implement blocking API by using wait condition
on the caller's side. Replay all collected
signals from the launcher's thread when leaving
waitingFor* state. In case we were not waiting
for anything deliver the signals asynchronously
from launcher's thread to the caller's thread.
Change-Id: Id44fe5f7ceaac407004984a1dfb6ea65f197d297
Reviewed-by: hjk <hjk@qt.io>
Implement the reply confirmation for the started signal.
After qtcreator_processlauncher starts a new process
we connect to its started() signal and post a reply through
the socket to the LauncherInterface with the information about
the new PID. ProcessLauncherImpl now emits the started signal
with a delay, just after the confirmation has been received.
Change-Id: I2689e8e97b17466bd1f6b32c01909c12d80fcdef
Reviewed-by: hjk <hjk@qt.io>
By default QProcess::readChannel() returns StandardOutput,
and since no one modifies it, it will always be the same.
No need for an assert.
Change-Id: Id55f75e5cce4f1b8eaef2ec3094d7b103c2f0238
Reviewed-by: hjk <hjk@qt.io>
Mark ProcessLauncherImpl canceled when the kill
request has been sent to the process launcher.
If ProcessLauncherImpl is canceled, ignore the
finished reply sent from process launcher.
Recheck the state inside stopProcess() method
after calling terminate() - in this way in case of
ProcessLauncherImpl we avoid calling unimplemented
waitForFinished().
Change-Id: Ibad148f6c7e63ef619e53eb41bbeeb7693be3d25
Reviewed-by: hjk <hjk@qt.io>
The initial implementation is a copy of QbsProcess
with some small adaptations. Start a LauncherProcess
in Creator's main function, just after the creation of
the application object.
Change-Id: I016df3ed664d7914c73f4a35742d5a63d5faaca0
Reviewed-by: hjk <hjk@qt.io>
Abstract part of QProcess interface into ProcessInterface
pure virtual class. The current API of ProcessInterface
is a part of QProcess API used currently to implement
QtcProcess. Provide 2 implementations for it: QProcessImpl
which uses QProcess and ProcessLauncherImpl which is currently
empty implementation with assertions that no method is being
called. Provide an additional switch to QtcProcess c'tor
for selecting the preferred implementation, by default it
selects QProcessImpl. This change doesn't influence any behavior.
Change-Id: Ia5328401affe127f3d36870be8478202d4143480
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
Keep SynchronousProcess as type alias for a transition period.
Change-Id: I2540b6cecc17eb46f40ed57d27589011693728f1
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
