2012-10-02 09:12:39 +02:00
|
|
|
/****************************************************************************
|
2008-12-02 12:01:29 +01:00
|
|
|
**
|
2016-01-15 14:57:40 +01:00
|
|
|
** Copyright (C) 2016 The Qt Company Ltd.
|
|
|
|
|
** Contact: https://www.qt.io/licensing/
|
2008-12-02 12:01:29 +01:00
|
|
|
**
|
2012-10-02 09:12:39 +02:00
|
|
|
** This file is part of Qt Creator.
|
2008-12-02 12:01:29 +01:00
|
|
|
**
|
2012-10-02 09:12:39 +02:00
|
|
|
** 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
|
2016-01-15 14:57:40 +01:00
|
|
|
** 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.
|
2008-12-02 14:17:16 +01:00
|
|
|
**
|
2016-01-15 14:57:40 +01:00
|
|
|
** 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.
|
2010-12-17 16:01:08 +01:00
|
|
|
**
|
2012-10-02 09:12:39 +02:00
|
|
|
****************************************************************************/
|
2008-12-02 16:19:05 +01:00
|
|
|
|
2008-12-02 12:01:29 +01:00
|
|
|
#include "abstractprocessstep.h"
|
2013-02-06 16:28:38 +01:00
|
|
|
#include "ansifilterparser.h"
|
2018-04-27 12:34:13 +02:00
|
|
|
#include "buildconfiguration.h"
|
2008-12-02 12:01:29 +01:00
|
|
|
#include "buildstep.h"
|
2018-11-17 21:19:04 +02:00
|
|
|
#include "ioutputparser.h"
|
|
|
|
|
#include "processparameters.h"
|
2008-12-02 12:01:29 +01:00
|
|
|
#include "project.h"
|
2018-06-19 11:04:47 +02:00
|
|
|
#include "target.h"
|
2011-08-18 13:46:52 +02:00
|
|
|
#include "task.h"
|
2008-12-02 16:19:05 +01:00
|
|
|
|
2016-12-05 21:14:40 +01:00
|
|
|
#include <coreplugin/reaper.h>
|
|
|
|
|
|
2019-03-13 16:06:12 +01:00
|
|
|
#include <utils/fileinprojectfinder.h>
|
2018-11-17 21:19:04 +02:00
|
|
|
#include <utils/fileutils.h>
|
2009-12-09 13:54:46 +01:00
|
|
|
#include <utils/qtcassert.h>
|
2018-11-17 21:19:04 +02:00
|
|
|
#include <utils/qtcprocess.h>
|
2009-12-09 13:54:46 +01:00
|
|
|
|
2012-02-15 10:42:41 +01:00
|
|
|
#include <QDir>
|
2018-11-17 21:19:04 +02:00
|
|
|
#include <QHash>
|
|
|
|
|
#include <QPair>
|
2019-03-13 16:06:12 +01:00
|
|
|
#include <QUrl>
|
2008-12-02 12:01:29 +01:00
|
|
|
|
2018-03-28 12:37:19 +02:00
|
|
|
#include <algorithm>
|
2018-11-17 21:19:04 +02:00
|
|
|
#include <memory>
|
2018-03-28 12:37:19 +02:00
|
|
|
|
2019-05-28 18:59:45 +02:00
|
|
|
using namespace Utils;
|
|
|
|
|
|
2018-11-17 21:19:04 +02:00
|
|
|
namespace ProjectExplorer {
|
2008-12-02 12:01:29 +01:00
|
|
|
|
2011-04-14 12:58:14 +02:00
|
|
|
/*!
|
|
|
|
|
\class ProjectExplorer::AbstractProcessStep
|
|
|
|
|
|
2013-06-05 14:29:24 +02:00
|
|
|
\brief The AbstractProcessStep class is a convenience class that can be
|
|
|
|
|
used as a base class instead of BuildStep.
|
2011-04-14 12:58:14 +02:00
|
|
|
|
|
|
|
|
It should be used as a base class if your buildstep just needs to run a process.
|
|
|
|
|
|
|
|
|
|
Usage:
|
|
|
|
|
\list
|
2013-02-06 08:50:23 +01:00
|
|
|
\li Use processParameters() to configure the process you want to run
|
2011-04-14 12:58:14 +02:00
|
|
|
(you need to do that before calling AbstractProcessStep::init()).
|
2013-02-06 08:50:23 +01:00
|
|
|
\li Inside YourBuildStep::init() call AbstractProcessStep::init().
|
|
|
|
|
\li Inside YourBuildStep::run() call AbstractProcessStep::run(), which automatically starts the process
|
2011-04-14 12:58:14 +02:00
|
|
|
and by default adds the output on stdOut and stdErr to the OutputWindow.
|
2013-02-06 08:50:23 +01:00
|
|
|
\li If you need to process the process output override stdOut() and/or stdErr.
|
2011-04-14 12:58:14 +02:00
|
|
|
\endlist
|
|
|
|
|
|
|
|
|
|
The two functions processStarted() and processFinished() are called after starting/finishing the process.
|
|
|
|
|
By default they add a message to the output window.
|
|
|
|
|
|
|
|
|
|
Use setEnabled() to control whether the BuildStep needs to run. (A disabled BuildStep immediately returns true,
|
|
|
|
|
from the run function.)
|
|
|
|
|
|
|
|
|
|
\sa ProjectExplorer::ProcessParameters
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/*!
|
|
|
|
|
\fn void ProjectExplorer::AbstractProcessStep::setEnabled(bool b)
|
|
|
|
|
|
2013-09-10 17:16:10 +02:00
|
|
|
Enables or disables a BuildStep.
|
2011-04-14 12:58:14 +02:00
|
|
|
|
2013-10-07 13:34:40 +02:00
|
|
|
Disabled BuildSteps immediately return true from their run function.
|
2013-09-10 17:16:10 +02:00
|
|
|
Should be called from init().
|
2011-04-14 12:58:14 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/*!
|
|
|
|
|
\fn ProcessParameters *ProjectExplorer::AbstractProcessStep::processParameters()
|
|
|
|
|
|
2013-09-10 17:16:10 +02:00
|
|
|
Obtains a reference to the parameters for the actual process to run.
|
2011-04-14 12:58:14 +02:00
|
|
|
|
2013-09-10 17:16:10 +02:00
|
|
|
Should be used in init().
|
2011-04-14 12:58:14 +02:00
|
|
|
*/
|
|
|
|
|
|
2018-11-17 21:19:04 +02:00
|
|
|
class AbstractProcessStep::Private
|
|
|
|
|
{
|
|
|
|
|
public:
|
2018-11-17 22:46:45 +02:00
|
|
|
Private(AbstractProcessStep *q) : q(q) {}
|
|
|
|
|
|
|
|
|
|
AbstractProcessStep *q;
|
2018-11-17 21:19:04 +02:00
|
|
|
std::unique_ptr<Utils::QtcProcess> m_process;
|
|
|
|
|
std::unique_ptr<IOutputParser> m_outputParserChain;
|
|
|
|
|
ProcessParameters m_param;
|
2019-03-13 16:06:12 +01:00
|
|
|
Utils::FileInProjectFinder m_fileFinder;
|
2018-11-17 22:46:45 +02:00
|
|
|
QByteArray deferredText;
|
2018-11-17 21:19:04 +02:00
|
|
|
bool m_ignoreReturnValue = false;
|
|
|
|
|
bool m_skipFlush = false;
|
2018-11-17 22:46:45 +02:00
|
|
|
|
|
|
|
|
void readData(void (AbstractProcessStep::*func)(const QString &), bool isUtf8 = false);
|
|
|
|
|
void processLine(const QByteArray &data,
|
|
|
|
|
void (AbstractProcessStep::*func)(const QString &),
|
|
|
|
|
bool isUtf8 = false);
|
2018-11-17 21:19:04 +02:00
|
|
|
};
|
|
|
|
|
|
2014-07-01 11:08:26 +02:00
|
|
|
AbstractProcessStep::AbstractProcessStep(BuildStepList *bsl, Core::Id id) :
|
2018-11-17 21:19:04 +02:00
|
|
|
BuildStep(bsl, id),
|
2018-11-17 22:46:45 +02:00
|
|
|
d(new Private(this))
|
2016-12-05 21:14:40 +01:00
|
|
|
{
|
|
|
|
|
}
|
2009-10-27 14:16:28 +01:00
|
|
|
|
2018-11-17 21:19:04 +02:00
|
|
|
AbstractProcessStep::~AbstractProcessStep()
|
|
|
|
|
{
|
|
|
|
|
delete d;
|
|
|
|
|
}
|
|
|
|
|
|
2011-04-14 12:58:14 +02:00
|
|
|
/*!
|
2013-09-10 17:16:10 +02:00
|
|
|
Deletes all existing output parsers and starts a new chain with the
|
2011-04-14 12:58:14 +02:00
|
|
|
given parser.
|
|
|
|
|
|
|
|
|
|
Derived classes need to call this function.
|
|
|
|
|
*/
|
|
|
|
|
|
2014-10-13 22:37:28 +03:00
|
|
|
void AbstractProcessStep::setOutputParser(IOutputParser *parser)
|
2009-12-09 13:54:46 +01:00
|
|
|
{
|
2018-11-17 21:19:04 +02:00
|
|
|
d->m_outputParserChain.reset(new AnsiFilterParser);
|
|
|
|
|
d->m_outputParserChain->appendOutputParser(parser);
|
2009-12-09 13:54:46 +01:00
|
|
|
|
2018-11-17 21:19:04 +02:00
|
|
|
connect(d->m_outputParserChain.get(), &IOutputParser::addOutput, this, &AbstractProcessStep::outputAdded);
|
|
|
|
|
connect(d->m_outputParserChain.get(), &IOutputParser::addTask, this, &AbstractProcessStep::taskAdded);
|
2009-12-09 13:54:46 +01:00
|
|
|
}
|
|
|
|
|
|
2011-04-14 12:58:14 +02:00
|
|
|
/*!
|
2013-09-10 17:16:10 +02:00
|
|
|
Appends the given output parser to the existing chain of parsers.
|
2011-04-14 12:58:14 +02:00
|
|
|
*/
|
2014-10-13 22:37:28 +03:00
|
|
|
void AbstractProcessStep::appendOutputParser(IOutputParser *parser)
|
2009-12-09 13:54:46 +01:00
|
|
|
{
|
|
|
|
|
if (!parser)
|
|
|
|
|
return;
|
|
|
|
|
|
2018-11-17 21:19:04 +02:00
|
|
|
QTC_ASSERT(d->m_outputParserChain, return);
|
|
|
|
|
d->m_outputParserChain->appendOutputParser(parser);
|
2009-12-09 13:54:46 +01:00
|
|
|
}
|
|
|
|
|
|
2014-10-13 22:37:28 +03:00
|
|
|
IOutputParser *AbstractProcessStep::outputParser() const
|
2009-12-09 13:54:46 +01:00
|
|
|
{
|
2018-11-17 21:19:04 +02:00
|
|
|
return d->m_outputParserChain.get();
|
2009-12-09 13:54:46 +01:00
|
|
|
}
|
|
|
|
|
|
2014-06-20 14:32:40 +02:00
|
|
|
void AbstractProcessStep::emitFaultyConfigurationMessage()
|
|
|
|
|
{
|
|
|
|
|
emit addOutput(tr("Configuration is faulty. Check the Issues view for details."),
|
2017-01-12 10:59:12 +01:00
|
|
|
BuildStep::OutputFormat::NormalMessage);
|
2014-06-20 14:32:40 +02:00
|
|
|
}
|
|
|
|
|
|
2011-09-22 12:59:31 +02:00
|
|
|
bool AbstractProcessStep::ignoreReturnValue()
|
|
|
|
|
{
|
2018-11-17 21:19:04 +02:00
|
|
|
return d->m_ignoreReturnValue;
|
2011-09-22 12:59:31 +02:00
|
|
|
}
|
|
|
|
|
|
2011-04-14 12:58:14 +02:00
|
|
|
/*!
|
2013-09-10 17:16:10 +02:00
|
|
|
If \a ignoreReturnValue is set to true, then the abstractprocess step will
|
2011-04-14 12:58:14 +02:00
|
|
|
return success even if the return value indicates otherwise.
|
|
|
|
|
|
|
|
|
|
Should be called from init.
|
|
|
|
|
*/
|
|
|
|
|
|
2009-10-15 19:06:51 +02:00
|
|
|
void AbstractProcessStep::setIgnoreReturnValue(bool b)
|
2009-06-22 16:11:45 +02:00
|
|
|
{
|
2018-11-17 21:19:04 +02:00
|
|
|
d->m_ignoreReturnValue = b;
|
2009-06-22 16:11:45 +02:00
|
|
|
}
|
|
|
|
|
|
2011-04-14 12:58:14 +02:00
|
|
|
/*!
|
2013-09-10 17:16:10 +02:00
|
|
|
Reimplemented from BuildStep::init(). You need to call this from
|
|
|
|
|
YourBuildStep::init().
|
2011-04-14 12:58:14 +02:00
|
|
|
*/
|
|
|
|
|
|
2019-01-10 15:31:44 +01:00
|
|
|
bool AbstractProcessStep::init()
|
2008-12-02 12:01:29 +01:00
|
|
|
{
|
2019-03-13 16:06:12 +01:00
|
|
|
d->m_fileFinder.setProjectDirectory(project()->projectDirectory());
|
|
|
|
|
d->m_fileFinder.setProjectFiles(project()->files(Project::AllFiles));
|
2018-11-17 21:19:04 +02:00
|
|
|
return !d->m_process;
|
2008-12-02 12:01:29 +01:00
|
|
|
}
|
|
|
|
|
|
2011-04-14 12:58:14 +02:00
|
|
|
/*!
|
2013-09-10 17:16:10 +02:00
|
|
|
Reimplemented from BuildStep::init(). You need to call this from
|
|
|
|
|
YourBuildStep::run().
|
2011-04-14 12:58:14 +02:00
|
|
|
*/
|
|
|
|
|
|
ProjectExplorer: Rework the build step run interface
Originally, the build manager used to run all build steps in a dedicated
thread. Communication between the step and the manager happened via a
QFutureInterface that was passed into the step's run() function.
Later, new steps were added that operated asynchronously, so the build
manager had to differentiate between the different kinds of steps for
starting and stopping.
These days, almost all build and deploy steps work asynchronously, which
made the QFuture-based interface look increasingly odd.
With this patch, all build steps are expected to work asynchronously, so
the build manager no longer needs to differentiate. Steps are started
and requested to stop via the run() and cancel() functions,
respectively, and emit the finished() signal when they are done. Build
step implementors no longer have to deal with a QFutureInterface. For
steps whose implementation is inherently synchronous, the BuildStep base
class offers a runInThread() function.
Change-Id: If905c68b234c5a669f6e19f43142eaa57d594803
Reviewed-by: hjk <hjk@qt.io>
2019-01-25 14:26:34 +01:00
|
|
|
void AbstractProcessStep::doRun()
|
2008-12-02 12:01:29 +01:00
|
|
|
{
|
2019-05-15 13:59:43 +02:00
|
|
|
QDir wd(d->m_param.effectiveWorkingDirectory().toString());
|
2014-10-22 12:29:41 +02:00
|
|
|
if (!wd.exists()) {
|
|
|
|
|
if (!wd.mkpath(wd.absolutePath())) {
|
|
|
|
|
emit addOutput(tr("Could not create directory \"%1\"")
|
|
|
|
|
.arg(QDir::toNativeSeparators(wd.absolutePath())),
|
2017-01-12 10:59:12 +01:00
|
|
|
BuildStep::OutputFormat::ErrorMessage);
|
ProjectExplorer: Rework the build step run interface
Originally, the build manager used to run all build steps in a dedicated
thread. Communication between the step and the manager happened via a
QFutureInterface that was passed into the step's run() function.
Later, new steps were added that operated asynchronously, so the build
manager had to differentiate between the different kinds of steps for
starting and stopping.
These days, almost all build and deploy steps work asynchronously, which
made the QFuture-based interface look increasingly odd.
With this patch, all build steps are expected to work asynchronously, so
the build manager no longer needs to differentiate. Steps are started
and requested to stop via the run() and cancel() functions,
respectively, and emit the finished() signal when they are done. Build
step implementors no longer have to deal with a QFutureInterface. For
steps whose implementation is inherently synchronous, the BuildStep base
class offers a runInThread() function.
Change-Id: If905c68b234c5a669f6e19f43142eaa57d594803
Reviewed-by: hjk <hjk@qt.io>
2019-01-25 14:26:34 +01:00
|
|
|
finish(false);
|
2014-10-22 12:29:41 +02:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-05 15:35:15 +02:00
|
|
|
const CommandLine effectiveCommand(d->m_param.effectiveCommand(),
|
|
|
|
|
d->m_param.effectiveArguments(),
|
|
|
|
|
CommandLine::Raw);
|
2019-05-28 18:59:45 +02:00
|
|
|
if (!effectiveCommand.executable().exists()) {
|
2014-01-13 17:16:33 +01:00
|
|
|
processStartupFailed();
|
ProjectExplorer: Rework the build step run interface
Originally, the build manager used to run all build steps in a dedicated
thread. Communication between the step and the manager happened via a
QFutureInterface that was passed into the step's run() function.
Later, new steps were added that operated asynchronously, so the build
manager had to differentiate between the different kinds of steps for
starting and stopping.
These days, almost all build and deploy steps work asynchronously, which
made the QFuture-based interface look increasingly odd.
With this patch, all build steps are expected to work asynchronously, so
the build manager no longer needs to differentiate. Steps are started
and requested to stop via the run() and cancel() functions,
respectively, and emit the finished() signal when they are done. Build
step implementors no longer have to deal with a QFutureInterface. For
steps whose implementation is inherently synchronous, the BuildStep base
class offers a runInThread() function.
Change-Id: If905c68b234c5a669f6e19f43142eaa57d594803
Reviewed-by: hjk <hjk@qt.io>
2019-01-25 14:26:34 +01:00
|
|
|
finish(false);
|
2014-01-13 17:16:33 +01:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-17 21:19:04 +02:00
|
|
|
d->m_process.reset(new Utils::QtcProcess());
|
|
|
|
|
d->m_process->setUseCtrlCStub(Utils::HostOsInfo::isWindowsHost());
|
|
|
|
|
d->m_process->setWorkingDirectory(wd.absolutePath());
|
|
|
|
|
d->m_process->setEnvironment(d->m_param.environment());
|
2019-05-28 18:59:45 +02:00
|
|
|
d->m_process->setCommand(effectiveCommand);
|
2008-12-02 12:01:29 +01:00
|
|
|
|
2018-11-17 21:19:04 +02:00
|
|
|
connect(d->m_process.get(), &QProcess::readyReadStandardOutput,
|
2016-01-29 16:38:37 +02:00
|
|
|
this, &AbstractProcessStep::processReadyReadStdOutput);
|
2018-11-17 21:19:04 +02:00
|
|
|
connect(d->m_process.get(), &QProcess::readyReadStandardError,
|
2016-01-29 16:38:37 +02:00
|
|
|
this, &AbstractProcessStep::processReadyReadStdError);
|
2019-02-26 09:40:49 +01:00
|
|
|
connect(d->m_process.get(), QOverload<int, QProcess::ExitStatus>::of(&QProcess::finished),
|
2016-01-29 16:38:37 +02:00
|
|
|
this, &AbstractProcessStep::slotProcessFinished);
|
2008-12-02 12:01:29 +01:00
|
|
|
|
2018-11-17 21:19:04 +02:00
|
|
|
d->m_process->start();
|
|
|
|
|
if (!d->m_process->waitForStarted()) {
|
2008-12-02 12:01:29 +01:00
|
|
|
processStartupFailed();
|
2018-11-17 21:19:04 +02:00
|
|
|
d->m_process.reset();
|
|
|
|
|
d->m_outputParserChain.reset();
|
ProjectExplorer: Rework the build step run interface
Originally, the build manager used to run all build steps in a dedicated
thread. Communication between the step and the manager happened via a
QFutureInterface that was passed into the step's run() function.
Later, new steps were added that operated asynchronously, so the build
manager had to differentiate between the different kinds of steps for
starting and stopping.
These days, almost all build and deploy steps work asynchronously, which
made the QFuture-based interface look increasingly odd.
With this patch, all build steps are expected to work asynchronously, so
the build manager no longer needs to differentiate. Steps are started
and requested to stop via the run() and cancel() functions,
respectively, and emit the finished() signal when they are done. Build
step implementors no longer have to deal with a QFutureInterface. For
steps whose implementation is inherently synchronous, the BuildStep base
class offers a runInThread() function.
Change-Id: If905c68b234c5a669f6e19f43142eaa57d594803
Reviewed-by: hjk <hjk@qt.io>
2019-01-25 14:26:34 +01:00
|
|
|
finish(false);
|
2008-12-02 12:01:29 +01:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
processStarted();
|
2019-01-28 09:59:24 +01:00
|
|
|
}
|
|
|
|
|
|
ProjectExplorer: Rework the build step run interface
Originally, the build manager used to run all build steps in a dedicated
thread. Communication between the step and the manager happened via a
QFutureInterface that was passed into the step's run() function.
Later, new steps were added that operated asynchronously, so the build
manager had to differentiate between the different kinds of steps for
starting and stopping.
These days, almost all build and deploy steps work asynchronously, which
made the QFuture-based interface look increasingly odd.
With this patch, all build steps are expected to work asynchronously, so
the build manager no longer needs to differentiate. Steps are started
and requested to stop via the run() and cancel() functions,
respectively, and emit the finished() signal when they are done. Build
step implementors no longer have to deal with a QFutureInterface. For
steps whose implementation is inherently synchronous, the BuildStep base
class offers a runInThread() function.
Change-Id: If905c68b234c5a669f6e19f43142eaa57d594803
Reviewed-by: hjk <hjk@qt.io>
2019-01-25 14:26:34 +01:00
|
|
|
void AbstractProcessStep::doCancel()
|
2019-01-28 09:59:24 +01:00
|
|
|
{
|
|
|
|
|
Core::Reaper::reap(d->m_process.release());
|
2018-11-17 21:19:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ProcessParameters *AbstractProcessStep::processParameters()
|
|
|
|
|
{
|
|
|
|
|
return &d->m_param;
|
2013-02-12 12:56:02 +01:00
|
|
|
}
|
2008-12-02 12:01:29 +01:00
|
|
|
|
2017-01-16 12:26:27 +01:00
|
|
|
void AbstractProcessStep::cleanUp(QProcess *process)
|
2013-02-12 12:56:02 +01:00
|
|
|
{
|
2008-12-02 12:01:29 +01:00
|
|
|
// The process has finished, leftover data is read in processFinished
|
2017-01-16 12:26:27 +01:00
|
|
|
processFinished(process->exitCode(), process->exitStatus());
|
2018-11-17 21:19:04 +02:00
|
|
|
const bool returnValue = processSucceeded(process->exitCode(), process->exitStatus()) || d->m_ignoreReturnValue;
|
2008-12-02 12:01:29 +01:00
|
|
|
|
2018-11-17 21:19:04 +02:00
|
|
|
d->m_outputParserChain.reset();
|
|
|
|
|
d->m_process.reset();
|
2013-02-12 12:56:02 +01:00
|
|
|
|
2016-04-20 12:49:25 +02:00
|
|
|
// Report result
|
ProjectExplorer: Rework the build step run interface
Originally, the build manager used to run all build steps in a dedicated
thread. Communication between the step and the manager happened via a
QFutureInterface that was passed into the step's run() function.
Later, new steps were added that operated asynchronously, so the build
manager had to differentiate between the different kinds of steps for
starting and stopping.
These days, almost all build and deploy steps work asynchronously, which
made the QFuture-based interface look increasingly odd.
With this patch, all build steps are expected to work asynchronously, so
the build manager no longer needs to differentiate. Steps are started
and requested to stop via the run() and cancel() functions,
respectively, and emit the finished() signal when they are done. Build
step implementors no longer have to deal with a QFutureInterface. For
steps whose implementation is inherently synchronous, the BuildStep base
class offers a runInThread() function.
Change-Id: If905c68b234c5a669f6e19f43142eaa57d594803
Reviewed-by: hjk <hjk@qt.io>
2019-01-25 14:26:34 +01:00
|
|
|
finish(returnValue);
|
2008-12-02 12:01:29 +01:00
|
|
|
}
|
|
|
|
|
|
2011-04-14 12:58:14 +02:00
|
|
|
/*!
|
2013-09-10 17:16:10 +02:00
|
|
|
Called after the process is started.
|
2011-04-14 12:58:14 +02:00
|
|
|
|
2013-09-10 17:16:10 +02:00
|
|
|
The default implementation adds a process-started message to the output
|
|
|
|
|
message.
|
2011-04-14 12:58:14 +02:00
|
|
|
*/
|
|
|
|
|
|
2008-12-02 12:01:29 +01:00
|
|
|
void AbstractProcessStep::processStarted()
|
|
|
|
|
{
|
2011-03-31 18:22:22 +02:00
|
|
|
emit addOutput(tr("Starting: \"%1\" %2")
|
2019-05-15 13:59:43 +02:00
|
|
|
.arg(QDir::toNativeSeparators(d->m_param.effectiveCommand().toString()),
|
2018-11-17 21:19:04 +02:00
|
|
|
d->m_param.prettyArguments()),
|
2017-01-12 10:59:12 +01:00
|
|
|
BuildStep::OutputFormat::NormalMessage);
|
2008-12-02 12:01:29 +01:00
|
|
|
}
|
|
|
|
|
|
2011-04-14 12:58:14 +02:00
|
|
|
/*!
|
2013-09-10 17:16:10 +02:00
|
|
|
Called after the process is finished.
|
2011-04-14 12:58:14 +02:00
|
|
|
|
2013-09-10 17:16:10 +02:00
|
|
|
The default implementation adds a line to the output window.
|
2011-04-14 12:58:14 +02:00
|
|
|
*/
|
|
|
|
|
|
2010-04-09 13:10:59 +02:00
|
|
|
void AbstractProcessStep::processFinished(int exitCode, QProcess::ExitStatus status)
|
2008-12-02 12:01:29 +01:00
|
|
|
{
|
2018-11-17 21:19:04 +02:00
|
|
|
if (d->m_outputParserChain)
|
|
|
|
|
d->m_outputParserChain->flush();
|
2013-05-03 16:08:00 +02:00
|
|
|
|
2019-05-15 13:59:43 +02:00
|
|
|
QString command = QDir::toNativeSeparators(d->m_param.effectiveCommand().toString());
|
2010-06-08 15:04:42 +02:00
|
|
|
if (status == QProcess::NormalExit && exitCode == 0) {
|
2010-11-09 11:55:04 +01:00
|
|
|
emit addOutput(tr("The process \"%1\" exited normally.").arg(command),
|
2017-01-12 10:59:12 +01:00
|
|
|
BuildStep::OutputFormat::NormalMessage);
|
2010-06-08 15:04:42 +02:00
|
|
|
} else if (status == QProcess::NormalExit) {
|
2010-07-15 10:29:38 +02:00
|
|
|
emit addOutput(tr("The process \"%1\" exited with code %2.")
|
2017-02-10 10:47:44 +01:00
|
|
|
.arg(command, QString::number(exitCode)),
|
2017-01-12 10:59:12 +01:00
|
|
|
BuildStep::OutputFormat::ErrorMessage);
|
2010-06-08 15:04:42 +02:00
|
|
|
} else {
|
2017-01-12 10:59:12 +01:00
|
|
|
emit addOutput(tr("The process \"%1\" crashed.").arg(command), BuildStep::OutputFormat::ErrorMessage);
|
2010-06-08 15:04:42 +02:00
|
|
|
}
|
2008-12-02 12:01:29 +01:00
|
|
|
}
|
|
|
|
|
|
2011-04-14 12:58:14 +02:00
|
|
|
/*!
|
2013-09-10 17:16:10 +02:00
|
|
|
Called if the process could not be started.
|
2011-04-14 12:58:14 +02:00
|
|
|
|
2013-09-10 17:16:10 +02:00
|
|
|
By default, adds a message to the output window.
|
2011-04-14 12:58:14 +02:00
|
|
|
*/
|
|
|
|
|
|
2008-12-02 12:01:29 +01:00
|
|
|
void AbstractProcessStep::processStartupFailed()
|
|
|
|
|
{
|
2010-10-19 11:14:03 +02:00
|
|
|
emit addOutput(tr("Could not start process \"%1\" %2")
|
2019-05-15 13:59:43 +02:00
|
|
|
.arg(QDir::toNativeSeparators(d->m_param.effectiveCommand().toString()),
|
2018-11-17 21:19:04 +02:00
|
|
|
d->m_param.prettyArguments()),
|
2017-01-12 10:59:12 +01:00
|
|
|
BuildStep::OutputFormat::ErrorMessage);
|
2010-04-09 13:10:59 +02:00
|
|
|
}
|
|
|
|
|
|
2011-04-14 12:58:14 +02:00
|
|
|
/*!
|
2013-09-10 17:16:10 +02:00
|
|
|
Called to test whether a process succeeded or not.
|
2011-04-14 12:58:14 +02:00
|
|
|
*/
|
|
|
|
|
|
2010-04-09 13:10:59 +02:00
|
|
|
bool AbstractProcessStep::processSucceeded(int exitCode, QProcess::ExitStatus status)
|
|
|
|
|
{
|
2013-08-21 11:40:00 +02:00
|
|
|
if (outputParser() && outputParser()->hasFatalErrors())
|
|
|
|
|
return false;
|
|
|
|
|
|
2010-04-09 13:10:59 +02:00
|
|
|
return exitCode == 0 && status == QProcess::NormalExit;
|
2008-12-02 12:01:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void AbstractProcessStep::processReadyReadStdOutput()
|
|
|
|
|
{
|
2018-11-17 21:19:04 +02:00
|
|
|
if (!d->m_process)
|
2017-01-16 12:26:27 +01:00
|
|
|
return;
|
2018-11-17 21:19:04 +02:00
|
|
|
d->m_process->setReadChannel(QProcess::StandardOutput);
|
2018-06-19 11:04:47 +02:00
|
|
|
BuildConfiguration *bc = buildConfiguration();
|
|
|
|
|
if (!bc)
|
|
|
|
|
bc = target()->activeBuildConfiguration();
|
|
|
|
|
const bool utf8Output = bc && bc->environment().hasKey("VSLANG");
|
2018-11-17 22:46:45 +02:00
|
|
|
d->readData(&AbstractProcessStep::stdOutput, utf8Output);
|
|
|
|
|
}
|
2018-04-27 12:34:13 +02:00
|
|
|
|
2018-11-17 22:46:45 +02:00
|
|
|
void AbstractProcessStep::Private::readData(void (AbstractProcessStep::*func)(const QString &),
|
|
|
|
|
bool isUtf8)
|
|
|
|
|
{
|
|
|
|
|
while (m_process->bytesAvailable()) {
|
|
|
|
|
const bool hasLine = m_process->canReadLine();
|
|
|
|
|
const QByteArray data = hasLine ? m_process->readLine() : m_process->readAll();
|
|
|
|
|
int startPos = 0;
|
|
|
|
|
int crPos = -1;
|
|
|
|
|
while ((crPos = data.indexOf('\r', startPos)) >= 0) {
|
2018-11-27 10:19:14 +02:00
|
|
|
if (data.size() > crPos + 1 && data.at(crPos + 1) == '\n')
|
|
|
|
|
break;
|
2018-11-17 22:46:45 +02:00
|
|
|
processLine(data.mid(startPos, crPos - startPos + 1), func, isUtf8);
|
|
|
|
|
startPos = crPos + 1;
|
|
|
|
|
}
|
|
|
|
|
if (hasLine)
|
|
|
|
|
processLine(data.mid(startPos), func, isUtf8);
|
|
|
|
|
else if (startPos < data.count())
|
|
|
|
|
deferredText += data.mid(startPos);
|
2008-12-02 12:01:29 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-17 22:46:45 +02:00
|
|
|
void AbstractProcessStep::Private::processLine(const QByteArray &data,
|
|
|
|
|
void (AbstractProcessStep::*func)(const QString &),
|
|
|
|
|
bool isUtf8)
|
|
|
|
|
{
|
|
|
|
|
const QByteArray text = deferredText + data;
|
|
|
|
|
deferredText.clear();
|
|
|
|
|
const QString line = isUtf8 ? QString::fromUtf8(text) : QString::fromLocal8Bit(text);
|
|
|
|
|
(q->*func)(line);
|
|
|
|
|
}
|
|
|
|
|
|
2011-04-14 12:58:14 +02:00
|
|
|
/*!
|
2013-09-10 17:16:10 +02:00
|
|
|
Called for each line of output on stdOut().
|
2011-04-14 12:58:14 +02:00
|
|
|
|
|
|
|
|
The default implementation adds the line to the application output window.
|
|
|
|
|
*/
|
|
|
|
|
|
2009-12-09 13:54:46 +01:00
|
|
|
void AbstractProcessStep::stdOutput(const QString &line)
|
2008-12-02 12:01:29 +01:00
|
|
|
{
|
2018-11-17 21:19:04 +02:00
|
|
|
if (d->m_outputParserChain)
|
|
|
|
|
d->m_outputParserChain->stdOutput(line);
|
2017-01-12 10:59:12 +01:00
|
|
|
emit addOutput(line, BuildStep::OutputFormat::Stdout, BuildStep::DontAppendNewline);
|
2008-12-02 12:01:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void AbstractProcessStep::processReadyReadStdError()
|
|
|
|
|
{
|
2018-11-17 21:19:04 +02:00
|
|
|
if (!d->m_process)
|
2017-01-16 12:26:27 +01:00
|
|
|
return;
|
2018-11-17 21:19:04 +02:00
|
|
|
d->m_process->setReadChannel(QProcess::StandardError);
|
2018-11-17 22:46:45 +02:00
|
|
|
d->readData(&AbstractProcessStep::stdError);
|
2008-12-02 12:01:29 +01:00
|
|
|
}
|
|
|
|
|
|
2011-04-14 12:58:14 +02:00
|
|
|
/*!
|
2013-09-10 17:16:10 +02:00
|
|
|
Called for each line of output on StdErrror().
|
2011-04-14 12:58:14 +02:00
|
|
|
|
2013-09-10 17:16:10 +02:00
|
|
|
The default implementation adds the line to the application output window.
|
2011-04-14 12:58:14 +02:00
|
|
|
*/
|
|
|
|
|
|
2008-12-02 12:01:29 +01:00
|
|
|
void AbstractProcessStep::stdError(const QString &line)
|
|
|
|
|
{
|
2018-11-17 21:19:04 +02:00
|
|
|
if (d->m_outputParserChain)
|
|
|
|
|
d->m_outputParserChain->stdError(line);
|
2017-01-12 10:59:12 +01:00
|
|
|
emit addOutput(line, BuildStep::OutputFormat::Stderr, BuildStep::DontAppendNewline);
|
2008-12-02 12:01:29 +01:00
|
|
|
}
|
|
|
|
|
|
ProjectExplorer: Rework the build step run interface
Originally, the build manager used to run all build steps in a dedicated
thread. Communication between the step and the manager happened via a
QFutureInterface that was passed into the step's run() function.
Later, new steps were added that operated asynchronously, so the build
manager had to differentiate between the different kinds of steps for
starting and stopping.
These days, almost all build and deploy steps work asynchronously, which
made the QFuture-based interface look increasingly odd.
With this patch, all build steps are expected to work asynchronously, so
the build manager no longer needs to differentiate. Steps are started
and requested to stop via the run() and cancel() functions,
respectively, and emit the finished() signal when they are done. Build
step implementors no longer have to deal with a QFutureInterface. For
steps whose implementation is inherently synchronous, the BuildStep base
class offers a runInThread() function.
Change-Id: If905c68b234c5a669f6e19f43142eaa57d594803
Reviewed-by: hjk <hjk@qt.io>
2019-01-25 14:26:34 +01:00
|
|
|
void AbstractProcessStep::finish(bool success)
|
2013-02-15 16:18:49 +01:00
|
|
|
{
|
ProjectExplorer: Rework the build step run interface
Originally, the build manager used to run all build steps in a dedicated
thread. Communication between the step and the manager happened via a
QFutureInterface that was passed into the step's run() function.
Later, new steps were added that operated asynchronously, so the build
manager had to differentiate between the different kinds of steps for
starting and stopping.
These days, almost all build and deploy steps work asynchronously, which
made the QFuture-based interface look increasingly odd.
With this patch, all build steps are expected to work asynchronously, so
the build manager no longer needs to differentiate. Steps are started
and requested to stop via the run() and cancel() functions,
respectively, and emit the finished() signal when they are done. Build
step implementors no longer have to deal with a QFutureInterface. For
steps whose implementation is inherently synchronous, the BuildStep base
class offers a runInThread() function.
Change-Id: If905c68b234c5a669f6e19f43142eaa57d594803
Reviewed-by: hjk <hjk@qt.io>
2019-01-25 14:26:34 +01:00
|
|
|
emit finished(success);
|
2013-02-15 16:18:49 +01:00
|
|
|
}
|
|
|
|
|
|
2015-04-20 17:13:45 +02:00
|
|
|
void AbstractProcessStep::taskAdded(const Task &task, int linkedOutputLines, int skipLines)
|
2009-12-09 13:54:46 +01:00
|
|
|
{
|
2010-04-09 13:10:59 +02:00
|
|
|
// Do not bother to report issues if we do not care about the results of
|
|
|
|
|
// the buildstep anyway:
|
2018-11-17 21:19:04 +02:00
|
|
|
if (d->m_ignoreReturnValue)
|
2010-04-09 13:10:59 +02:00
|
|
|
return;
|
|
|
|
|
|
2013-05-03 16:08:00 +02:00
|
|
|
// flush out any pending tasks before proceeding:
|
2018-11-17 21:19:04 +02:00
|
|
|
if (!d->m_skipFlush && d->m_outputParserChain) {
|
|
|
|
|
d->m_skipFlush = true;
|
|
|
|
|
d->m_outputParserChain->flush();
|
|
|
|
|
d->m_skipFlush = false;
|
2013-05-03 16:08:00 +02:00
|
|
|
}
|
|
|
|
|
|
2010-03-12 13:53:00 +01:00
|
|
|
Task editable(task);
|
2012-01-26 13:38:25 +01:00
|
|
|
QString filePath = task.file.toString();
|
2019-03-13 16:06:12 +01:00
|
|
|
if (!filePath.isEmpty() && !filePath.startsWith('<') && !QDir::isAbsolutePath(filePath)) {
|
|
|
|
|
while (filePath.startsWith("../"))
|
|
|
|
|
filePath.remove(0, 3);
|
|
|
|
|
bool found = false;
|
2019-05-28 13:49:26 +02:00
|
|
|
const Utils::FilePathList candidates
|
2019-03-13 16:06:12 +01:00
|
|
|
= d->m_fileFinder.findFile(QUrl::fromLocalFile(filePath), &found);
|
|
|
|
|
if (found && candidates.size() == 1)
|
|
|
|
|
editable.file = candidates.first();
|
|
|
|
|
else
|
|
|
|
|
qWarning() << "Could not find absolute location of file " << filePath;
|
2009-12-09 13:54:46 +01:00
|
|
|
}
|
2018-03-28 12:37:19 +02:00
|
|
|
|
2015-04-20 17:13:45 +02:00
|
|
|
emit addTask(editable, linkedOutputLines, skipLines);
|
2009-12-09 13:54:46 +01:00
|
|
|
}
|
|
|
|
|
|
2014-10-13 22:37:28 +03:00
|
|
|
void AbstractProcessStep::outputAdded(const QString &string, BuildStep::OutputFormat format)
|
2009-12-09 13:54:46 +01:00
|
|
|
{
|
2011-03-31 18:22:22 +02:00
|
|
|
emit addOutput(string, format, BuildStep::DontAppendNewline);
|
2009-12-09 13:54:46 +01:00
|
|
|
}
|
|
|
|
|
|
2008-12-02 12:01:29 +01:00
|
|
|
void AbstractProcessStep::slotProcessFinished(int, QProcess::ExitStatus)
|
|
|
|
|
{
|
2018-11-17 21:19:04 +02:00
|
|
|
QProcess *process = d->m_process.get();
|
2017-01-16 12:26:27 +01:00
|
|
|
if (!process) // Happens when the process was canceled and handed over to the Reaper.
|
|
|
|
|
process = qobject_cast<QProcess *>(sender()); // The process was canceled!
|
|
|
|
|
|
|
|
|
|
const QString stdErrLine = process ? QString::fromLocal8Bit(process->readAllStandardError()) : QString();
|
|
|
|
|
for (const QString &l : stdErrLine.split('\n'))
|
|
|
|
|
stdError(l);
|
2008-12-02 12:01:29 +01:00
|
|
|
|
2017-01-16 12:26:27 +01:00
|
|
|
const QString stdOutLine = process ? QString::fromLocal8Bit(process->readAllStandardOutput()) : QString();
|
|
|
|
|
for (const QString &l : stdOutLine.split('\n'))
|
|
|
|
|
stdError(l);
|
2008-12-09 11:07:24 +01:00
|
|
|
|
2017-01-16 12:26:27 +01:00
|
|
|
cleanUp(process);
|
2008-12-02 12:01:29 +01:00
|
|
|
}
|
2018-03-28 12:37:19 +02:00
|
|
|
|
2018-11-17 21:19:04 +02:00
|
|
|
} // namespace ProjectExplorer
|