After this one, is compiles with the opt-in macro. Not changed yet,
though.
Change-Id: I29a66ecb5daa71d0d97566b81fd9f47d92f6368a
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
... by some out-of-band mechanism, keeping previous functionality.
The driving reason is to get the same fromMap signature as in the
AspectContainer base, however, the whole mechanism seems rather useless:
There are only a few places that actually ever could report errors,
in those places "moving on" looks ok, too, and these few places
are not conceptually different than a lot others.
Removal of this (new) mechanism is left for later.
Change-Id: Ibe7a0456bc3b84a84e942231f14446e783372d76
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
To match better with the rest, especially the base AspectContainer.
Change-Id: Ide0966cab3219800aa6b7b9e6012731a3fbe7a6f
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Move the doRun() implementation from AbstractProcessStep
and from AbstractRemoteLinuxDeployStep into BuildStep.
Do the same with doCancel().
Task-number: QTCREATORBUG-29168
Change-Id: I767f73dc7408d7c5a9fe9821da92e664cf1ed8f3
Reviewed-by: hjk <hjk@qt.io>
Make it behave like AbstractProcessStep.
Move success / failure logging into the recipe.
Make starting the task tree look the same in both classes.
That's a preparation step before moving running task tree
into the base BuildStep class.
Task-number: QTCREATORBUG-29168
Change-Id: I2bf3e2476d3942a01efc3b06778410dea40eef5e
Reviewed-by: hjk <hjk@qt.io>
Move some methods into protected section.
Do some cleanup.
Change-Id: Ica6f6fd181334c450666049c10d9ecc1ea16ea5c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
There is no need for extra nested Group item in deployRecipe()
overloads, as sometimes it's just one task, like in case of
QdbStopApplicationStep or CustomCommandDeployStep.
Change-Id: I89cdb703c24198f3cbdfb17d0317e40f1929c376
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This is a preparation step toward making the recipe more general.
Add a runRecipe() method (private for now) which
describes the whole step's execution. Later, when
virtual BuildStep::runRecipe() is added, we just
make this newly added method virtual.
Make deployRecipe() pure virtual.
Change-Id: Ic9c4e3eea7d4a3eb95fd419575f4f747224d0499
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Short live Tasking in Solutions!
Add src/libs/solutions/README.md with the motivation and hints.
Move TaskTree and Barrier from Utils into Tasking object lib,
the first solution in Solutions project.
Tasking: Some more work is still required for adapting auto and
manual tests. Currently they use Async task, which stayed in Utils.
For Qt purposed we most probably need to have a clone of
Async task inside the Tasking namespace that is more Qt-like
(no Utils::FutureSynchronizer, no priority field,
global QThreadPool instead of a custom one for Creator).
Change-Id: I5d10a2d68170ffa467d8c299be5995b9aa4f8f77
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Not needed since the deploy step and service hierarchy merge.
Change-Id: I644bdeca31caa2182b9d618e5f1ec6865c95f4c8
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
They were 1:1 now.
The change here is as small as possible, there are quite a few places
to clean up left.
Change-Id: I4f78d1de857b93d8372e2592a7723b02fe2fc947
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Plan is to merge the class hierarchies, this is a mechanical first step.
Change-Id: I163578297a4badb5b8c861283f0d6a44c25f124f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
QMap::unite() is gone, the replacement insert() came late, so ask
the preprocessor for help.
Task-number: QTCREATORBUG-24098
Change-Id: I2f596f9a998fa795fe0df378a39c4f1267f4e6e7
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Now only one piece of code needs to be written to both linkify output in
an output pane and create tasks for it in the issues pane.
The calling sites are also simplified. For instance, until now, build
steps had to feed their output parsers manually and then push the
created tasks up the signal stack in parallel with the actual output,
which the build manager relied upon for cross-linking the output pane
content. Afterwards, the output would get forwarded to the formatter
(and parsed for ANSI escape codes a second time). In contrast, a build
step now just forwards the process output, and task parsing as well as
output formatting is done centrally further up the stack.
Concrete user-visible improvements so far:
- File paths in compiler/linker messages are clickable links now.
- QtTest applications now create clickable links also when run
as part of a build step, not just in the app output pane.
Task-number: QTCREATORBUG-22665
Change-Id: Ic9fb95b2d97f2520ab3ec653315e9219466ec08d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
For Compile, BuildSystem and Deployment. Unclutters user code and reduces
binary size.
Change-Id: Ia18e917bb411754162e9f4ec6056d752a020bb50
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
More in line with QFileInfo terminonlogy which appears to be
best-of-breed within Qt.
Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Instead of the combined bool value + QString * out parameter.
Change-Id: I8840f48b74aaacd1b0c0412efd8abcdc2be12d58
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
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>
... by base DeployConfiguration and adapt remaining users.
Change-Id: I6e2a0ab0c9b682b221de0089f8768b5e621e0025
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The extra parameter was always computed but used only in one place,
and that use got removed lately.
Change-Id: Ie10c0107ca70ee97ce03f83294992aab8d1a3ffe
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The in-between 'false' default value was reverted further down
twice and only used as such once.
Change-Id: I3017c1328a0fa036b0fb66d6955ee1b0585697f3
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The extra m_step member is not worth the abstraction, especially
since almost all non-SimpleBuildStepWidget have something similar,
too. Also, as several derived classes needed to correct
SimpleBuildStepWidget's setShowWidget(false).
Change-Id: I6e80d8c84c363b90dc27c70abd7fa6cefa1ed91e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This follow the rough pattern of recent *RunConfigurationFactory changes
for build and deploy configurations.
- Collapse the two lines of constructors similar to what
890c1906e6 did for RunConfigurations
* Deploy* was purely mechanical
* Build* ctors are split in connects() in the ctor body
to create "empty shell for clone" etc
and build step additions in initialize() functions which
are only used in the create() case.
-- Allows to collapse the shared 'ctor()' functions, too.
- Move FooBuildConfigurationFactory::create() implementations
to FooBuildConfiguration() constructor. That was a strange
and unneeded ping-pong between factories and objects, and
furthermore allows one level less of indirection (and for a
later, left out here, some reduction of the
FooBuildConfiguration interfaces that were only used to
accommodate the *Factory::create() functions.
- Most {Build,Deploy}Configuration{,Factory} classes had a canHandle(),
but there wasn't one in the base classses. Have one there.
- Most canHandle() functions were checking simple restrictions on
e.g. project or target types, specify those by setters in the
constructors instead and check them in the base canHandle()
- clone() is generally replaced by a creation of a "shell object"
and a fromMap(source->toMap()), implemented in the base, there
are two cases left for Android and Qbs that needed(?) some extra
polish
- generally use canHandle() in base implementation, instead
of doing that in all Derived::canFoo()
- as a result, canCreate/create/canClone/clone reimplementations
are not needed anymore, keep the base implementation for
now (could be inlined into their only users later), but
de-virtualize them.
- Combine Ios{Preset,DSym}BuildStepFactory. There was only one
'dsym' build step they could create.
- Split the 'mangled' id into the ProjectConfiguration subtype
specific constant identifier, and a QString extraId() bit.
Only maintain the mangled id in saved settings.
- Make ProjectConfiguration::m_id a constant member, adapt
all constructors of derived classe.
Not done in this patch:
- Finish possible cosmetic changes on top
- Add a way to specify restrictions to supported Qt versions
(used in Android/Ios), as the base implementation does not
depend on the qtsupport plugin
- Combine the QList<X> availableFoo() + createFoo(X) function
pairs to somthing like a direct
QList<struct { X; std::function<X()>; }> fooCreators()
to avoid e.g. the baseId.withSuffix() <-> id.suffixAfter(base)
pingpong
- Remove the *Factories from the global object pool
- Do something about priority(). Falling back to plain
qmake in android+qmake setup is not helpful.
Change-Id: I2be7d88d554c5aa8b7db8edf5b93278e1ae0112a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The old ones did not convey their meaning very well. In particular,
NormalOutput and MessageOutput were easily confused.
Change-Id: Ia0a8c1b1c366ab3f5c59f751b37b8b1f68f6831d
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The heavy lifting was done by clazy.
Change-Id: I1a03435bbb4281bad4ff64baba0182e0050170d6
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Remove the finished() signal that is (sometimes) used to report that
a buildstep is done and use the FutureInterface for that purpose
consistently.
Change-Id: Ibe5520b562b91f1a7f4fc73ee898b33b930029ec
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
This information can be used to get information from earlier steps,
which e.g. queried for android devices to deploy to.
Change-Id: Iefe1c9443915cb6211f86f98ff7aaf3cb75145ba
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
Clicking on error messages is supposed to jump to the editor.
And "Show Output" on the task is supposed to select the error
in the output.
The old code just registered the task for the last line of
output. This broke for every parser that allowed for
error messages that spanned multiple lines. And was obviously
also incorrect for tasks that weren't generated due to
compile output.
Fix both of those issues by giving the IOutputParsers more
control on which lines are linked to a task.
Task-number: QTCREATORBUG-14136
Change-Id: I095922c9875620dabfb7d406f6b152c8a9b25b62
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
