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

178 lines
6.6 KiB
C++
Raw Normal View History

// Copyright (C) 2016 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0
#include "cmakeprocess.h"
#include "builddirparameters.h"
#include "cmakeparser.h"
#include "cmakeprojectconstants.h"
#include "cmakeprojectmanagertr.h"
#include "cmakespecificsettings.h"
#include <coreplugin/progressmanager/processprogress.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>
using namespace Core;
using namespace ProjectExplorer;
using namespace Utils;
namespace CMakeProjectManager::Internal {
static QString stripTrailingNewline(QString str)
{
if (str.endsWith('\n'))
str.chop(1);
return str;
}
CMakeProcess::CMakeProcess() = default;
CMakeProcess::~CMakeProcess()
{
m_parser.flush();
}
static const int failedToStartExitCode = 0xFF; // See QtcProcessPrivate::handleDone() impl
void CMakeProcess::run(const BuildDirParameters &parameters, const QStringList &arguments)
{
QTC_ASSERT(!m_process, return);
CMakeTool *cmake = parameters.cmakeTool();
QTC_ASSERT(parameters.isValid() && cmake, return);
const FilePath cmakeExecutable = cmake->cmakeExecutable();
if (!cmakeExecutable.ensureReachable(parameters.sourceDirectory)) {
const QString msg = ::CMakeProjectManager::Tr::tr(
"The source directory %1 is not reachable by the CMake executable %2.")
.arg(parameters.sourceDirectory.displayName()).arg(cmakeExecutable.displayName());
BuildSystem::appendBuildSystemOutput(msg + '\n');
emit finished(failedToStartExitCode);
return;
}
if (!cmakeExecutable.ensureReachable(parameters.buildDirectory)) {
const QString msg = ::CMakeProjectManager::Tr::tr(
"The build directory %1 is not reachable by the CMake executable %2.")
.arg(parameters.buildDirectory.displayName()).arg(cmakeExecutable.displayName());
BuildSystem::appendBuildSystemOutput(msg + '\n');
emit finished(failedToStartExitCode);
return;
}
const FilePath sourceDirectory = cmakeExecutable.withNewMappedPath(parameters.sourceDirectory);
const FilePath buildDirectory = cmakeExecutable.withNewMappedPath(parameters.buildDirectory);
if (!buildDirectory.exists()) {
const QString msg = ::CMakeProjectManager::Tr::tr(
"The build directory \"%1\" does not exist").arg(buildDirectory.toUserOutput());
BuildSystem::appendBuildSystemOutput(msg + '\n');
emit finished(failedToStartExitCode);
return;
}
if (buildDirectory.needsDevice()) {
if (cmake->cmakeExecutable().host() != buildDirectory.host()) {
const QString msg = ::CMakeProjectManager::Tr::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(failedToStartExitCode);
return;
}
}
// Copy the "package-manager" CMake code from the ${IDE:ResourcePath} to the build directory
if (Internal::CMakeSpecificSettings::instance()->packageManagerAutoSetup.value()) {
const FilePath localPackageManagerDir = buildDirectory.pathAppended(Constants::PACKAGE_MANAGER_DIR);
const FilePath idePackageManagerDir = FilePath::fromString(
parameters.expander->expand(QStringLiteral("%{IDE:ResourcePath}/package-manager")));
if (!localPackageManagerDir.exists() && idePackageManagerDir.exists())
idePackageManagerDir.copyRecursively(localPackageManagerDir);
}
const auto parser = new CMakeParser;
parser->setSourceDirectory(parameters.sourceDirectory);
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);
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(::CMakeProjectManager::Tr::tr("Running %1 in %2.")
.arg(commandLine.toUserOutput(), buildDirectory.toUserOutput()));
ProcessProgress *progress = new ProcessProgress(m_process.get());
progress->setDisplayName(::CMakeProjectManager::Tr::tr("Configuring \"%1\"")
.arg(parameters.projectName));
m_process->setTimeoutS(10); // for process progress timeout estimation
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);
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_process->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
void CMakeProcess::handleProcessDone(const Utils::ProcessResultData &resultData)
{
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 = ::CMakeProjectManager::Tr::tr("CMake process failed to 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
} else if (resultData.m_exitStatus != QProcess::NormalExit) {
if (resultData.m_canceledByUser)
msg = ::CMakeProjectManager::Tr::tr("CMake process was canceled by the user.");
else
msg = ::CMakeProjectManager::Tr::tr("CMake process crashed.");
} else if (code != 0) {
msg = ::CMakeProjectManager::Tr::tr("CMake process exited with exit code %1.").arg(code);
}
if (!msg.isEmpty()) {
BuildSystem::appendBuildSystemOutput(msg + '\n');
TaskHub::addTask(BuildSystemTask(Task::Error, msg));
}
emit finished(code);
const QString elapsedTime = Utils::formatElapsedTime(m_elapsed.elapsed());
BuildSystem::appendBuildSystemOutput(elapsedTime + '\n');
}
} // CMakeProjectManager::Internal