There is a recurring special case that certain run controls depend
on the presence of specific RunConfiguration (which in turn has
it's own restriction on e.g. target or project types) but have no
further restrictions.
Make it easy to handle that case.
Change-Id: I2e86f366591b02003f720dcc00b4c52bb2f34e00
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>
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>
There's several hundred kBytes extra for the separate .o in a
debug build, this doesn't scale well for a handful lines of code.
As the Nim plugin is a nice template for others elsewise, it would
be nice to use scalable patterns only.
Change-Id: I78e473d28a6a63d458dcbe06a77d93221867417f
Reviewed-by: Filippo Cucchetto <filippocucchetto@gmail.com>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
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>
That's adapting to the introduction and use of extra runconfig aspects
a while ago.
Change-Id: I216aa409679b6b81bf3b6fa7c4473147616962a6
Reviewed-by: David Schulz <david.schulz@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>
