This avoids the "catch all" that leads to conflicts with more specific
setups like the AppManagerRunConfig, and consequently lets us remove
the priorities in the RunWorkerFactories.
Change-Id: I382f00ca7f759eef995ac6fe749bb371ab027020
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@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>
It is often possible to user (member) functions or members directly.
That improves readablility and potentially reduces the total number of
symbols.
Also use qobject_container_cast at places where it is appropriate.
Change-Id: Ia2591bca356591e001e2c53eeebcf753e5bc3c37
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Do not crash when the cmake tool that was used to parse the project
gets removed.
Change-Id: Ieda3ae2025dbcfb1f90d9bd01c5f0ed960756c6a
Reviewed-by: Ulf Hermann <ulf.hermann@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>
Report an error when a project can not get parsed.
Change-Id: I659a5ffb465b4a2de39910b05e7eef2481b9ad70
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@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>
The project tree will sort the nodes as needed, so there is no
need to sort the list beforehand.
Change-Id: I1ee71100aba003117c918c5295224ec1253dc807
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Remove FolderNode::addNestedNodes that take raw pointers now that the
last user is gone.
Change-Id: If2ca3864934d9239ac136e65c0b7dbcea7caf220
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This has been superseded by other items, most notably the buildKey.
Incidentally, even Creator 4.6 is robust enough to handle .user files
without the CMakeProjectManager.CMakeRunConfiguation.Title key without
problem.
Change-Id: Iaecb2c15b31ebfb78146c0bec8b955ae821e4499
Reviewed-by: Tobias Hunger <tobias.hunger@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>
DesktopQmake, CMake, Qbs, Nim, RemoteLinux and Qnx now have a common
understanding what should be in a runnable and how their
configuration widget should be set up. So move them over to
using shared code, too.
Several others runconfigs only lack a one or two more aspects
to follow suit in later patches.
Change-Id: Ia862c95c97d63bd0a0f2dc303435775a2fc530d3
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Tobias Hunger <tobias.hunger@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>
Report project-specific warnings about the kit used in Project Mode.
E.g. a python project should not complain about missing toolchains,
while a qmake project should.
Change-Id: I5ce6742683cdeffc7ff3f1a3e8f0b89aee9aa0b4
Reviewed-by: Thomas Hartmann <thomas.hartmann@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>
Margins and layout style widely differ so far. Start moving everything
to a QFormLayout with the same margin and growth policy.
Change-Id: I0bd1d8b2ec9830be56354be1376a2a24eebb8845
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Some translations moved over to the corresponding RunConfigurations,
one setParent() replaced by direct deletion.
Change-Id: Ib5e527b71353a6be70b332ac2dfd2f5cd2499a60
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
"cmake --build ." is useful to build, clean and deploy, so offer it
everywhere.
This fixes soft asserts as a side effect when loading cmake projects with
existing "cmake --build . --target=clean" in their clean steps.
Change-Id: I39e5866f6012b9ea1153da324e4abd1cd25fea92
Reviewed-by: hjk <hjk@qt.io>
This removes the outermost layer of widget-vbox and moves some
common code into a helper function.
The pattern repeats (with variations) a few more times, that's
left for later patches.
Change-Id: I8c98229cf41d03d5330c896ec9fa0965bfc65602
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
processEvents is a bad way of dealing with asynchronous
requests. Use QFutureWatcher for that purpose.
Change-Id: I3839cb9db80a6d391f6af1178e96986a325b7b99
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
Anything remote is being taken care of by the target specific factories,
having CMakeRunConfigurationFactory accept everything too leads to
unhelpful duplicated entries.
Change-Id: I7e509593f6eaed8ee75ef0acef1703a877b1f011
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Funnel all relevant data through target.applicationTargets() as
done for the non-local CMake-supporting setups and QBS already.
There is cleanup potential left for later changes.
Change-Id: I49ed6abd98c058a7fd1545e41b3bcd6ecb758a8b
Task-number: QTCREATORBUG-19985
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
