Files
qt-creator/src/plugins/cmakeprojectmanager/cmakeprocess.cpp

213 lines
6.6 KiB
C++
Raw Normal View History

/****************************************************************************
**
** Copyright (C) 2016 The Qt Company Ltd.
** Contact: https://www.qt.io/licensing/
**
** This file is part of Qt Creator.
**
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and The Qt Company. For licensing terms
** and conditions see https://www.qt.io/terms-conditions. For further
** information use the contact form at https://www.qt.io/contact-us.
**
** GNU General Public License Usage
** Alternatively, this file may be used under the terms of the GNU
** General Public License version 3 as published by the Free Software
** Foundation with exceptions as appearing in the file LICENSE.GPL3-EXCEPT
** included in the packaging of this file. Please review the following
** information to ensure the GNU General Public License requirements will
** be met: https://www.gnu.org/licenses/gpl-3.0.html.
**
****************************************************************************/
#include "cmakeprocess.h"
#include "cmakeparser.h"
#include <coreplugin/progressmanager/progressmanager.h>
#include <projectexplorer/buildsystem.h>
#include <projectexplorer/projectexplorerconstants.h>
#include <projectexplorer/taskhub.h>
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
#include <utils/processinterface.h>
#include <utils/qtcprocess.h>
#include <utils/stringutils.h>
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
#include <QFutureInterface>
using namespace Utils;
namespace CMakeProjectManager {
namespace Internal {
using namespace ProjectExplorer;
static QString stripTrailingNewline(QString str)
{
if (str.endsWith('\n'))
str.chop(1);
return str;
}
CMakeProcess::CMakeProcess()
{
connect(&m_cancelTimer, &QTimer::timeout, this, &CMakeProcess::checkForCancelled);
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
m_cancelTimer.setInterval(50);
}
CMakeProcess::~CMakeProcess()
{
m_process.reset();
m_parser.flush();
if (m_future) {
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
// None of the progress related functions will work after this!
m_future->reportCanceled();
m_future->reportFinished();
}
}
void CMakeProcess::run(const BuildDirParameters &parameters, const QStringList &arguments)
{
QTC_ASSERT(!m_process && !m_future, return);
CMakeTool *cmake = parameters.cmakeTool();
QTC_ASSERT(parameters.isValid() && cmake, return);
const FilePath cmakeExecutable = cmake->cmakeExecutable();
const FilePath sourceDirectory = parameters.sourceDirectory.onDevice(cmakeExecutable);
const FilePath buildDirectory = parameters.buildDirectory.onDevice(cmakeExecutable);
if (!buildDirectory.exists()) {
QString msg = tr("The build directory \"%1\" does not exist")
.arg(buildDirectory.toUserOutput());
BuildSystem::appendBuildSystemOutput(msg + '\n');
emit finished();
return;
}
if (buildDirectory.needsDevice()) {
if (cmake->cmakeExecutable().host() != buildDirectory.host()) {
QString msg = tr("CMake executable \"%1\" and build directory "
"\"%2\" must be on the same device.")
.arg(cmake->cmakeExecutable().toUserOutput(), buildDirectory.toUserOutput());
BuildSystem::appendBuildSystemOutput(msg + '\n');
emit finished();
return;
}
}
const auto parser = new CMakeParser;
parser->setSourceDirectory(parameters.sourceDirectory.path());
m_parser.addLineParser(parser);
// Always use the sourceDir: If we are triggered because the build directory is getting deleted
// then we are racing against CMakeCache.txt also getting deleted.
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
m_process.reset(new QtcProcess);
m_processWasCanceled = false;
m_cancelTimer.start();
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
m_process->setWorkingDirectory(buildDirectory);
m_process->setEnvironment(parameters.environment);
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
m_process->setStdOutLineCallback([](const QString &s) {
BuildSystem::appendBuildSystemOutput(stripTrailingNewline(s));
});
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
m_process->setStdErrLineCallback([this](const QString &s) {
m_parser.appendMessage(s, StdErrFormat);
BuildSystem::appendBuildSystemOutput(stripTrailingNewline(s));
});
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
connect(m_process.get(), &QtcProcess::done, this, [this] {
handleProcessDone(m_process->resultData());
});
CommandLine commandLine(cmakeExecutable);
commandLine.addArgs({"-S", sourceDirectory.path(), "-B", buildDirectory.path()});
commandLine.addArgs(arguments);
TaskHub::clearTasks(ProjectExplorer::Constants::TASK_CATEGORY_BUILDSYSTEM);
BuildSystem::startNewBuildSystemOutput(
tr("Running %1 in %2.").arg(commandLine.toUserOutput()).arg(buildDirectory.toUserOutput()));
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
m_future.reset(new QFutureInterface<void>);
m_future->setProgressRange(0, 1);
Core::ProgressManager::addTimedTask(*m_future.get(),
tr("Configuring \"%1\"").arg(parameters.projectName),
"CMake.Configure",
10);
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
m_process->setCommand(commandLine);
emit started();
m_elapsed.start();
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
m_process->start();
}
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
void CMakeProcess::stop()
{
if (m_process) {
m_processWasCanceled = true;
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
m_process->close();
handleProcessDone({15, QProcess::CrashExit, QProcess::Crashed, {}});
}
}
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
void CMakeProcess::handleProcessDone(const Utils::ProcessResultData &resultData)
{
QTC_ASSERT(m_future, return);
m_cancelTimer.stop();
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
const int code = resultData.m_exitCode;
QString msg;
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
if (resultData.m_error == QProcess::FailedToStart) {
msg = tr("CMake process failed to start.");
} else if (resultData.m_exitStatus != QProcess::NormalExit) {
if (m_processWasCanceled)
msg = tr("CMake process was canceled by the user.");
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
else
msg = tr("CMake process crashed.");
} else if (code != 0) {
msg = tr("CMake process exited with exit code %1.").arg(code);
}
m_lastExitCode = code;
if (!msg.isEmpty()) {
BuildSystem::appendBuildSystemOutput(msg + '\n');
TaskHub::addTask(BuildSystemTask(Task::Error, msg));
m_future->reportCanceled();
} else {
m_future->setProgressValue(1);
}
m_future->reportFinished();
emit finished();
const QString elapsedTime = Utils::formatElapsedTime(m_elapsed.elapsed());
BuildSystem::appendBuildSystemOutput(elapsedTime + '\n');
}
void CMakeProcess::checkForCancelled()
{
if (!m_process || !m_future)
return;
if (m_future->isCanceled()) {
m_cancelTimer.stop();
CMakeProcess: Fix stopping the CMake process Calling QtcProcess::terminate() doesn't guarantee that process will be terminated, especially on Windows we may ofter wait for it forever. Replace the call to terminate() with close(). After calling close(), the process will sooner or later be terminated (or finally killed) - that's the job for ProcessReaper. Since the current code relies on receiving the finished() signal after calling a stopping method, we need to call the expected handler (handleProcessDone()) after calling the QtcProcess::close(), as afterwards we can't expect receiving any signal for the possibly running process anymore. Refactor the code so that we connect do QtcProcess::done() signal instead of connecting to QtcProcess::finished() signal. This guarantees that the handler will also be called when process failed to start. Handle this case in done() handler, too. Rename CMakeProcess::terminate() into CMakeProcess::stop() in order to avoid confusion on what method we have chosen to stop the process in fact. That's the implementation detail. Get rid of some QFuture related handlings from public API. Use them directly from inside CMakeProcess d'tor. Get rid of public state() method, as it seems it's unused. Increase the responsiveness of small [x] icon of the running cmake task (reduce the timeout of 500 ms into 50 ms). Fixes: QTCREATORBUG-27518 Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0 Reviewed-by: <github-actions-qt-creator@cristianadam.eu> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2022-05-13 18:22:03 +02:00
stop();
}
}
} // namespace Internal
} // namespace CMakeProjectManager