The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... by base DeployConfiguration and adapt remaining users.
Change-Id: I6e2a0ab0c9b682b221de0089f8768b5e621e0025
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Keep the generality of creating any widget, but also add a convenience
function handling the single special case that was ever used.
Change-Id: Iab4cbe62de04b9fcc6cb0bb305eaf9a48649d991
Reviewed-by: Christian Kandeler <christian.kandeler@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>
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>
Currently we pass in some places by value, elsewhere by const ref and
for some weird reason also by const value in a lot of places. The latter
is particularly annoying, as it is also used in interfaces and therefore
forces all implementors to do the same, since leaving the "const" off is
causing compiler warnings with MSVC.
Change-Id: I65b87dc3cce0986b8a55ff6119cb752361027803
Reviewed-by: hjk <hjk121@nokiamail.com>
Ran script to remove inludes on a trial-and-error basis and
manually corrected it.
Change-Id: Ie7559562218ecab65da17f58e3515556a4a1d5c5
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
It is the same as NamedWidget. If we need to add additional
functionality then we can always reintroduce the class.
Change-Id: I684b5215e732e480e4e73e4cac3753bb92afd0d4
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
To createConfigWidget(). Which indicates that a new widget is created
and makes it the same name as BuildStep/BuildConfiguration
Change-Id: Ib1858bc5382556ebb9a8a474fa79f0e7e9593cf7
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Instead use the newly added abstractions from ProjectExplorer.
This makes the plugin qmake-independent in principle; any build system
can be used as long as the respective QtCreator plugin provides a way to
set up the required deployment information.
As a side effect of this patch, two features are lost:
(1) The ability to add a remote directory automatically for a
RemoteLinux based target. This was rarely ever useful, because any non-
trivial project requires more files to be deployed than just one binary.
(2) The ability to add Desktop files and icons for Fremantle and
Harmattan projects. Similar points as above apply here as well; such
projects should be set up via QtCreator's wizards or manually by users
who know what they are doing.
Change-Id: I2d7e621256f01143aafe3b191b04a120f053e672
Reviewed-by: Tobias Hunger <tobias.hunger@nokia.com>
More Profile use, less dependency on QtSupport,
Derive qtVersionId from profile instead of qt build configuration.
Replace qt4BuildConfiguration with buildConfiguration.
Use IDevice base class in AbstractRemoteLinuxApplicationRunner
and in other places. Simplify remote linux runconfiguration
Change-Id: I6414d3d8146d16c360b3a0465c57a052ea71f899
Reviewed-by: Christian Kandeler <christian.kandeler@nokia.com>
Introduce Profiles to store sets of values that describe a system/device.
These profiles are held by a target, getting rid of much of the information
stored in the Build-/Run-/DeployConfigurations, greatly simplifying those.
This is a squash of the wip/profile branch which has been on gerrit for a
while, rebased to current master.
Change-Id: I25956c8dd4d1962b2134bfaa8a8076ae3909460f
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
We had a mixed style until now (mostly using const refs). Use value
semantics everywhere for consistency and hope that the class never gets
heavier.
Change-Id: Ic9536f87b01a76252bd8643c8681b3dc9067a266
Reviewed-by: Tobias Hunger <tobias.hunger@nokia.com>
Use Core::Id for all the project related objects in favor of plain
QStrings.
Change-Id: I790ab40cb29899efdb49c413a77609486f52e683
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
It seems pointless to have two identity-related concepts in parallel.
The new approach is as follows: The identifier is a Core::Id. If the
client code supplies a fingerprint string (as needed for auto-detected
devices), the id is derived from it, otherwise it gets created from a
newly generated UUID.
Change-Id: I680afa6cd2fdd43ec1c461616ba982b3ff55c73a
Reviewed-by: Tobias Hunger <tobias.hunger@nokia.com>
- to match other toMap() declarations
- to make it usable from subclasses
Change-Id: I0dcc1643fc37f3c327cc0fb2fb2dd1eca99f96fb
Reviewed-by: Nicolas Arnaud-Cormos <nicolas@kdab.com>
Reviewed-by: Christian Kandeler <christian.kandeler@nokia.com>
Getting the #include directives ready for Qt5. This includes the
new-project wizards.
Change-Id: Ia9261f1e8faec06b9285b694d2b7e9a095978d2b
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
All these things were always conceptually per-target, but due to not
having a common target class we had to awkwardly implement the concept
using shared pointers.
Change-Id: I1bb1992a230a485d519a892a6ca602a6846fc3cf
Reviewed-by: Tobias Hunger <tobias.hunger@nokia.com>
- Introduce generic and Madde-specific deploy configuration widgets.
- Move project file update logic into dedicated class.
- Generic deploy configuration widget no longer has the ability to change deployment settings via the GUI, because we cannot know which qmake scope to use for that.
Change-Id: Ie542a0852c8aa1c6b416cd7aece4e48c1cc2de7c
Reviewed-on: http://codereview.qt.nokia.com/2445
Reviewed-by: Christian Kandeler <christian.kandeler@nokia.com>
They still had "Maemo" in their names, even though
they are not Maemo-specific (and will not move
to the respective plugin).
Change-Id: I5eec0de27db8340f2a987a6ed685b3ae46ec17b0
Reviewed-on: http://codereview.qt.nokia.com/2036
Reviewed-by: Christian Kandeler <christian.kandeler@nokia.com>
