Rename process.h back to qtcprocess.h
MSVC's "threads" standard header includes <process.h>, and that ends up
including our process.h from Utils.
There already was a hacky workaround in place for a similar issue with
MINGW, but that doesn't work with MSVC because that doesn't have
Simply use a name that doesn't conflict.
Change-Id: I1159cd2096b4f2dbc4a1728d0131dd6edd30ebd3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
It may happen that textOnStandardOutput() sends multi lines,
even when they were sent by two separate std::cout with std::endl.
Instead of checking whether the 2nd expected line starts with
the magic word, check whether the message contains it.
Limit timeouts so that the test should pass about 3 seconds faster.
Change-Id: Ie4e4df70b62854eb595d41272fe4fa9bdec606fc
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Add an extra arg to runBlocking() function instead.
Use std::chrono::seconds for timeout.
Change-Id: I7c3c21e8f26a2ccbed157d15083d6ef0b4cd2f7e
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Rename ProcessResult::Hang into Canceled.
Change the behavior of the Process:
Whenever the terminate() or kill() is called, including
indirect calls through stop() or runBlocking()'s timeout,
mark the process result as Canceled.
In this way the Process running by a call to start()
may also finish with Canceled state. Before it was only
happening for processes started via runBlocking().
Adapt the runBlockingStdOut_data() test accordingly.
Get rid of ProcessInterface::m_canceledByUser field.
Use ProcessResult::Canceled state instead.
Fix existing 3 usages of m_canceledByUser field.
Use standarized exitMessage() method for them.
Add automatic measurement of process execution.
Introduce processDuration() getter.
Use it for reporting exitMessage() instead of timeoutS().
Change-Id: I1a68559ce844caef863a97a6b0577b0238011f70
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Avoid using readAllStandard{Output,Error} mutable methods if possible.
Use non-mutable methods when we are not connected to
readyReadStandard{Output,Error} signals.
Change-Id: I2e830e571b9eab2177fd856bbe06dfc5137d9c01
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Queue the call to start() so that it's executed after the nested
event loop is started, otherwise it fails on Windows with QProcessImpl.
Fixes: QTCREATORBUG-30066
Change-Id: Ibb17ef0f668f52c05b26a521e18c94e637992ba5
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It looks like when the running process outputs the newlines,
reading it may be split into separate chunks.
Avoid newlines in this test and use std::flush instead.
Amends bc3e30e7ec
Change-Id: I46be774b5509a1f0f60b289f6b6ffc9b46955b8f
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Since it's not clear why the flakiness existed, leave a TODO note.
Change-Id: Ief1104870c008e056d5b87880b508fd66266bce4
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Currently it works only in case of ProcessLaucher implementation.
The issue with QProcess implementation is that we need to
select the active channel in advance with QProcess::setReadChannel(),
what really doesn't make sense, since we can't predict on which
channel we will receive the data.
Currently we don't have setReadChannel() method inside Process API.
Change-Id: I23592e37f2ed5e3326bead445a9c6c6500d0e615
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
The flakiness happened on mac inside recursiveBlockingProcess test.
Change-Id: I4d461fcdae1ecbf29f89bfdb4ad7ba017724f14b
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
