Keeping the build graphs of all enabled targets in memory does not
scale.
Task-number: QTCREATORBUG-20622
Change-Id: Iab711e7e789db51a5ee13aa9bf3c9fbb2e08aa89
Reviewed-by: hjk <hjk@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>
As it already exists in the qmake project manager.
Task-number: QTCREATORBUG-20411
Change-Id: I8673e091b3f5772fdc1ddcac0e567f690960f1dd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Support for this was either forgotten in the initial implementation or
accidentally removed.
Change-Id: I4e35b8063bd0b847459d630e7c8ca0d7b09835aa
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
All other KitInformation sub classes do that, and if the ID is left
empty we run into strange corner cases.
Change-Id: I61047f077d49945a94bc93c28f0e9cb48e4bbe8e
Task-number: QTCREATORBUG-20636
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
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>
... by default. The "New File" wizard, if not invoked from the context
menu, implicitly prefers Groups over Products, because the respective
nodes are tried first. Thus, we lower the priority of group nodes so
that their parent product will be a better match unless the group was
specifically selected.
Task-number: QTCREATORBUG-20480
Change-Id: I0c5b2dbf861065ee97ab957ec8bd86132295893e
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>
Once it was enabled, the value passed to qbs would never get reset.
Task-number: QTCREATORBUG-20377
Change-Id: I366cba77ef56d81dcdaf619c697c60396eeec651
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
By default, that setting should not be enabled in release mode. That's
also how the QmakeProjectManager behaves.
Change-Id: Ifc5ed93b37b3f3f13ee19c5072f327794ea88144
Reviewed-by: Ulf Hermann <ulf.hermann@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>
... in run configurations. One check was missing.
This amends c6cd9e8fbe.
Change-Id: If398a719adbb5a5c2a527b70d274751ada91abe4
Reviewed-by: Christian Stenger <christian.stenger@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>
As convenience function, and use it in some places.
Change-Id: I02e49f2cdc301bbf1261836032d3fa3a5b188446
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>
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>
It's been like that for a long time, but the behavior was inadvertantly
changed in a recent refactoring.
Change-Id: I2f301c995c1f9bb235718e02326c4c64dea91694
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
And use it to handle adding extra library path for qbs and qmake and
and the DYLD debug suffix for qmake.
Could possibly be used more uniformly at some stage e.g. for CMake.
Change-Id: I0c4581b4e36960fc76d056c65c487d7c43a1be08
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
We do not ship clang-cl anymore which makes it impossible
to run clang with MSVC options.
Secondly we used to we tweak compiler options quite a bit so
why not to switch to CompilerOptionsBuilder totally?
Change-Id: Id323cb554587afaea7d9aa530e947a45a03922d1
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@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>
... with the paths of libraries used at link time. The value can still
be set per run config.
Task-number: QTCREATORBUG-20240
Change-Id: Ibe2425e95d791f93af2fba85a64be8bde6b31f5a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@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>
Setting up the qbs run environment is not free, and the respective code
gets triggered from other plugins much more often than expected.
Task-number: QTCREATORBUG-20175
Change-Id: I6529718d20738140963486caef103d6d17958d50
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Use new ExecutableAspect, simplify working directory and
'use terminal' access.
Change-Id: I1daca3a30a4a46f3e1ad0019a49d28279cbc885f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Easier to keep one variable in sync than three, and moves
the code closer towards a unified pattern in the local
runconfigurations.
Change-Id: I2df09127d476be4ddab466f8a709a2b383a76b97
Reviewed-by: Christian Kandeler <christian.kandeler@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>
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>
Two missing after 9541aa777, some inconsistent before.
Change-Id: I2ee330fb099cf8b8060fbbe3f375e77d4d9ff420
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
