All implementations that were returning true effectively did that
in case of node->buildKey() == rc->buildKey(), either directly or
in disguise of qmake's projectPath, so this is the check that is
used now in the two places where this is used.
The new global has the theoretical potential of return true in
cases where it did not before.
Change-Id: Ic5829de5fef0f9a04d516a3d9207685055823775
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Put the remaining device related pieces into a new IosDeviceTypeAspect.
Change-Id: Ia1ce2002edebedc2d409edc1144ade0ffe24a084
Reviewed-by: Vikas Pachdha <vikas.pachdha@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>
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>
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>
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>
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>
Most other signatures look like RunConfiguration::initialize(Core::Id),
this here is part of unifying them completely.
Change-Id: I7cd2acc8ebe6ec8cef05272f18f0fa5ded94f930
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
Moving aspect data closer to real Value semantics fixes
the regression introduced by 890c1906e.
Task-number: QTCREATORBUG-19186
Task-number: QTCREATORBUG-19192
Change-Id: Ieaeef3995ae06a817f266c1e2514f9e5793bd4e8
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The idea is to massage the setup in a way to make implementation
of new configurations less error prone by identifying recurring patterns
and sharing repetitive code that tends to be forgotten (see Android cloning).
The former two lines of constructors (owner-and-id, owner-and-source)
are split into a simple, shared, constructor and new setId() and
copyFrom() functions.
The change is mostly mechanical, some multiple calls to fromMap
have been removed, though, some consts added.
Otherwise, to keep the patch small it temporarily introduces two
helper templates in IRunConfigurationFactory. Also, setId() signatures
have not been unified yet. These won't be needed in the final setup.
Change-Id: I8c0734496caae744a9883fe6d92c1d8f8e0234ea
Reviewed-by: hjk <hjk@qt.io>
... and use this as a base for all RunConfigurations.
Clean out code in the individual run configurations dealing with their
enabled/disabled state.
Change-Id: Icc2ea136b056f7aea7ce96480b4402459d7ac0ce
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Introduce a method that maps a RunConfiguration to the build system target
that created the executable.
Implement the method in all RunConfigurations where that makes sense (e.g.
no CustomExecutables).
Change-Id: Ifaac859c2cd9b2806a0d7c185b2239312a67752a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
get simulator type and SDK version dynamically from the available ones,
and let the user choose which one to use.
This fixes the static solution that did break with Xcode 6
Change-Id: I5cb2be68b9ea8736fc880cf3dd9d39d77f030293
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@theqtcompany.com>
We now update after the profile has parsed, not when it is changed.
Change-Id: I70bf9bed85c77677d0ece0d7b99dff590a9e4d47
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
disabling running when running is not possible with message explaining
it:
* device is not available (and tell user if another device is available)
* profile parsings
Change-Id: I8a2e8e4486555b09de2ac4ceab89997286c81454
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
first work in progress support for ios
* separate iosTool using xml communication used for device info and run
* iossim tool to handle the simulator
* debug prepared but not working
* separate gcc toolchain detection fix for simulator
1) add a QT built for ios
2) open a project, for example qtbase/examples/widgets/animation/animatedtiles/animatedtiles.pro
3) build/run...
Change-Id: I7e01604e416338cbe4692dfb34f5d3f31312702d
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
