... 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>
Specifies the main purpose more clearly. The remaining ones a "true"
(internal) variants in models and as action data.
Change-Id: I8dd3c846e419f29d88283c2f48268ef6685b19fe
Reviewed-by: Eike Ziller <eike.ziller@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>
The main QtcProcess interface is nowadays a CommandLine, with no
explicit references left to QtcProcess::Arguments and related static
helper functions, so it only clutters the QtcProcess class interface
So move these items out of QtcProcess, later potentially to a separate
file pair.
Change-Id: I45c300b656f5b30e2e2717232c855fdd97c2d1d7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
After the previous changes it was only an empty wrapper around QWidget.
Change-Id: I58dcd82d8342c7de5e2df537044f6cf3de878a67
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The step is the source of information anyway, and available at the
only place of use. No need to copy that over to the widget, neither
for keeping it up-to-date there when the mechanism is already
available in the step itself.
This creates quite some potential for the simplification of
the various createConfigWidget implementations in follow-up patches.
Change-Id: I4474665f194a1ff7c5792ad086ed53c8d3ce13e6
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
1. Systematically check for AbstractProcessStep::init() first in
derived classes.
2. Use setupProcessParameters(processParameters()); by default in
the base implementation.
3. Drop all re-implementations that are effectively the same.
Change-Id: I0ae54dd4909b354672a63ee56d0b7c2ea0732494
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For convenience, and use it in some places.
Change-Id: I8f7cb502b37b2fbf4cf2d17cac9c6299558332dc
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>
Use "flat" aggregation instead.
This is another step towards the formatter/parser merger.
Along the way, also fix some some subclasses (mostly in BareMetal) that
erroneously forwarded handled output to other parsers.
Task-number: QTCREATORBUG-22665
Change-Id: I12947349ca663d2e6bbfc99efd069d69e2b54969
Reviewed-by: hjk <hjk@qt.io>
All parsers can now have search directories, not just the GnuMakeParser.
This allows us to get rid of the "task mangling", removing another
instance where the order of parsers in the chain mattered.
Task-number: QTCREATORBUG-22665
Change-Id: Id0d55522ae6800afd9f50ff36546224b0d8bb382
Reviewed-by: hjk <hjk@qt.io>
... and use in ProcessStep and related classes.
Change-Id: Ie6f1403d0aa2b9f5bcde06e994809466700b1357
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Allows to use constants in fewer places, similar to what e.g.
RunConfiguration does.
Change-Id: I9d049128206c4acf0ce14b06b66d6c090a7c5242
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... for build step related widgets. These are specifig to a build step
which in turn is only interested in its own build config and target.
Change-Id: I5ec277ba279932d18a615e528acffaccdc41e307
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... by a Project::buildConfigurationChanged. That's the only case
used, and saves filtering on the receiver side. Also, the passed
bc is (in non-null) the active one, so isActive checks are not
necessary.
The null case seems to be only possible to trigger when removing
the currently active build configuration manually i.e. happens rarely,
so having it trigger an unneeded final display update on the dying
build config is tolerable, so drop the null check in such cases
to achieve a more uniform pattern.
Change-Id: I46f72e9e277767214dbd6920dd86b026a7084f46
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Updating on changes to other build config seem excessive, as the
updated details only depend the owning build config.
Change-Id: Iba86f2b56033ac55381d452dd2a435e5dda72674
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Targets are different from {Run,Build,Deployment}Configurations,
both regarding the level in the ProjectExplorer hierarchy, and
also by the set of supported operations (e.g. aspects).
Change-Id: Ia8490e2280a9ecc518395c5e48ce2fd5d6d58fd2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... over setting command and args individually.
Change-Id: Iec7c8d3a0b05fb8fa0639f7ddbe7ccdc7387d2a2
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>
For the command and the working directory.
Change-Id: Ia69dc7100aeb57bb6e1b35f4dd4f3cf3763d8cda
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>
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>
Default to false, remove all no-op reimplementations.
And rename the getter to isImmutable according to the rules.
Change-Id: I8cce79d88fb59badfa1cffcf30a46f7ff3b09e8b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
From a virtual function to a normal one backed by a real data member.
That's essentially what several re-implementations did, the other
ones used a fixed value instead.
Change-Id: I61e45f1d4f7f0f80fe2eb1f2729785f37e7bb803
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Use BuildStep::displayName() as default.
This probably could be the only possibility, but currently there
are some discrepancies that are kept in this patch to make
the patch mechanical.
Change-Id: I2a1e5c2ff37ad95e25309eb16e07099e42191f60
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>
If a step is part of a build configuration, that is used, but many steps
can be used as part of a deploy configuration.
In that case the active build configuration of the step's target must be
used, and that logic was duplicated many times.
Instead, let BuildStep::buildConfiguration take care of that logic. For
steps that are not offered for deploy configurations there is no
semantic difference, and for the others this removes code duplication.
Change-Id: I02f3bb50226590092cedcec02fce6fde9c7c6e63
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Make the build steps apply to more buildsteplists.
Task-number: QTCREATORBUG-19823 (and similar for other build steps)
Change-Id: I09d3b4b6ad99453cb587303aa78b46e8a4f360bb
Reviewed-by: Eike Ziller <eike.ziller@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>
Fix crashes due to activeProjectConfigurationChanged signal sending
a nullptr.
Uses the same fix as QTCREATORBUG-18865, but in more places:-)
Task-number: QTCREATORBUG-18866
Change-Id: Ic71af5ed26b2a44339f0c687f3f46bfdf62c2489
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Add a subscribeSignal method to targets and projects that will make
sure all signals of all project configurations added during the lifetime
of the project/target will get connected (if the type matches).
Use this to connect to some signal in all BuildConfigurations of
a project and get rid of code that keeps connecting to the current
build configuration.
Use Project::buildEnvironmentChanged as an example and convert its
usages.
Change-Id: I689bcebac4b191bf3f8a18765bf18eaac371c5fe
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
