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>
... for display name, icon, and "can create".
Also add a convenience function for the special icon setup that's
used in all re-implementations.
Change-Id: I8332adb38fb4a77b6992007ffe62f861339ba188
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Instead, set the default level of all logs to QtWarningMsg.
The call to setFilterRules overrides the user preferences in qtlogging.ini.
Change-Id: Id5f6cd550d14ff7f45ae04c5d3110e0bafb0f072
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: hjk <hjk@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>
... to the single user.
As effect, all but the ios re-implementation are not needed.
Change-Id: I3c8b8c5d4ab3c8eac70c0bd534c5f1b33f8a3063
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
With a 1:1 mapping of factory and created device types, the signatures
of the device factory methods are much simpler, and yield even in
the cases where a factory created more than one device type
(WinRt and Qdb) less code after duplication of the factory.
Change-Id: I1c6279a88e8483001e5603cfe1922029243be610
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Using aspects is the standard pattern nowadays, there's nothing 'extra'
to them anymore.
Change-Id: I446f9d7b1db58a4899e5e44df33ce51f655e7be4
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Put the remaining device related pieces into a new IosDeviceTypeAspect.
Change-Id: Ia1ce2002edebedc2d409edc1144ade0ffe24a084
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
To remove the last user of IRCAspect::runConfiguration.
Change-Id: I1390166730112008a4050877f96bb29f274e7ef1
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
It has been an obsolete alias for setId for a while and downstream
uses have been adapted.
Change-Id: I467370aa67054599c7771e8275d28e62ddc461fa
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This replaces various versions of the key name of the arguments,
working directory, use terminal and use dyld image suffix fields
by unified versions ("RunConfiguration.Arguments",
"RunConfiguration.WorkingDirectory", "RunConfiguration.UseTerminal",
"RunConfiguration.UseDyldImageSuffix").
The different names for the fields are technically not needed
(as proven by several cases that already now used the same key),
partially outdated ("Qt4ProjectManager.MaemoRunConfiguration.Arguments")
make RunConfiguration constructors less uniform and more complex
than needed.
The "RunConfiguration." prefix in the new names is not needed, but used
by several other settings, so having it there looks more uniform now.
In (the unexpected case) that different keys would ever be necessary,
the default key name could still be overridden by using setSettingsKey
from user code.
Change-Id: Ifb74ad74e0a9c724c8bf5e71e1bb2424d5d1831b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Replace GenericLinuxFlavor, GenericUnixFlavor, GenericDarwinFlavor,
GenericQnxFlavor and GenericBareMetalFlavor with GenericFlavor. They
can all be distinguished from each other by the OS property, so having
separate enum values for all of them is not necessary.
Remove a unit test that made sure that each flavor (with exceptions)
is only listed for one OS, which no longer is the case now.
Change-Id: I88dad5d37eaa4c288568e40b95337a39b78a8352
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
De-QObject-ify class, tr contexts are now the product's
context, which was the case in some BuildStepFactories already,
and is current state in {Run,DeployConfiguration}Factory.
One spurious object name removed.
De-virtualize canHandle(), it was never overloaded and is not
intended to be overloaded anymore.
Remove unused clone() function.
Change-Id: Iff7fba5f707505f868f94458084a18650535fa23
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Casting all elements of a container, similar to qobject_container_cast.
Change-Id: Ib455fe8c7fa0d4acda7e29685c3100638a0152f8
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
As all Runnables are known to be StandardRunnables, this here
essentially replaces all .is<StandardRunnable> by 'true'.
.as<StandardRunnable> by no-op, and fixes the fallout.
Change-Id: I1632f8e164fa0a9dff063df47a9e191fdf7bbb2e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
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>
This also treats the arguments list as an arguments list for running,
not as a single argument.
Change-Id: Ia95e02c6324947081147b8bf8084cdd3a7d1eaf0
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
Despite its name, it's not the base for RunConfig (main) widgets, but
one for the "true" extra aspects (debugger, valgrind, perf, ...)
Change-Id: I45f3339ab2620fe4c55d77bd464f7770b51c30dd
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
The base ProjectExplorer::BuildConfiguration carries enough information
nowadays.
Change-Id: Ia5ce243aef68a109e70809f385c2c2ce2f072c2a
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
It's what the base class wants, and follows run and deploy precedence.
Change-Id: I26eff43337851702417e7e4284fc390b904060f6
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This follows some of the recent changes to RunConfigurations:
- pass Id from factory to DeployConfiguration constructors
- de-object-ify DeployConfigurationFactory
- use addSupportedTargetDeviceType(Id) instead of
addSupportedTargetDeviceType(List<Id>)
Also, use stepList()->appendStep() instead of stepList()->insertStep(pos...)
with manual pos tracking in some cases.
Change-Id: I09c6a9d0f66f9f85b1c13361104f7878028e1ea8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It's what the base class requires, and opens the possibility to
have several factories creating the same type of run configuration.
Also move ios, winrt and android factories closer to their products,
it's the predominant pattern nowadays.
Change-Id: Iad48152f02a248d22cb18dd435a2fc34d73c7077
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The parent widget is always given by the layout, no need to pass
it as separate parameter.
Change-Id: I9e7ed3a89eb63b78a549471d839060131737ff78
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
In cases where plugins extend an existing settings category of a plugin
that they depend on anyhow, they do not need to specify the translated
display name and icon for that category.
Some options pages were already not setting the icon, but still the
translated name, which makes even less sense.
Clean up this mess, only setting display name and icon if that is
necessary.
Change-Id: I8bc9d0c51b11d48f1d847337838704d663e70b45
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Note that the concept of a single monolithic OutputFormatter per
RunConfiguration (and why RunConfiguration, not RunControl to start
with?) is unchanged and suboptimal as one cannot easily combine
existing use cases, e.g. Python_and_Qt.
Change-Id: Ibeb8191020387324f22ed313230293597f96e36a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The previously per-Project/RunConfiguration changing meanings of
BuildTargetInfo::buildTarget have by now been split
into separate values in BuildTargetInfo:
- buildKey a handle to one item in Target::applicationTargetList
- displayName a user-visible string in the run settings page
The buildKey was tweaked to coincide with the previous 'extraId',
i.e. the non-RunConfiguration-type part of the project configuration
id that (still) use id mangling.
This allows replacing the cases of locally stored seven different
versions of buildKey(-ish) data by one RunConfiguration::m_buildKey,
and do all remaining extraId handling in RC::{from,to}Map only,
i.e. remove the base ProjectConfiguration::extraId() virtual and
remove the "re-try fromMap with mangled id" hack entirely.
The id mangling is still used to temporarily maintain .user file
compatibility in some cases for now, but should be replaced by
storing the build key and the RunConfiguration type soon. Qbs
already changes in here to only use the uniqueProductName as
buildKey, without the previously added display name which is
stored as part of the ProjectConfiguration already.
It turns out that RunConfiguration::buildSystemTarget was intended
and used to retrieve an item from the Target::applicationTargetList
for some configurations, coinciding with what buildKey does always.
So use that insteand and drop RunConfiguration::buildSystemTarget.
There is clearly is further consolidation potential left.
handling of (default)displayNames is still a per-runconfiguration
mess and there is further consolidation potential left.
Change-Id: I448ed30f1b562fb91b970e328a42fa5f6fb2e43e
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>
Make #includes self-contained, anticipating breakage in the upcoming
removal of projectexplorer/runconfiguration.h in qmakeproject.h
Change-Id: I7e7bc6224cde3f350d1880a97953e0e94ac5a80a
Reviewed-by: hjk <hjk@qt.io>
This feature in question is the availability of the "Run" button in the
context menu of certain project nodes in the project tree to run
something presumably related to/build from that (sub)project.
Previously, the decision was made for certain qmake based projects
(those targeting Desktop, iOS and VxWorks) by some indirection
through the corresponding RunConfigurationFactories.
The patch lets the RunConfigurations decide themselves directly
and removes the indirection, potentially opening the feature for
other qmake based RCs, as well as other combinations (e.g.
PythonRunConfiguration could be associated with its .py file,
without the need to have a dummy project)
Change-Id: Ic489bd1dfa25fcd9102ffa4fa30125565dd2e40e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
