Previous uses of canOffer are effectively unchanged in behavior,
other plain uses of canHandle now also check the additional
requirements on the Qt version on Android (the only platform
that had a custom hasBuildTarget() implementation). This is
assumed to make no difference in practice.
Change-Id: If12895d1421d5565ff91a18bf4d7df96c8191160
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It only ever returned either an empty list, or a list with a single
empty string. Using a bool return value to distiguish the cases is
less convoluted.
This is a leftover from the time when a DeployConfigurationFactory
could potentially create more than on DeployConfiguration, but this
is not supported anymore, as factories are cheap nowadays.
Change-Id: I4f2a91d3509d2b978949211ee709863d5ff460c7
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This uses the same approach as in the previous patches: Have some
generic interface in the base classes (here ProjectNode::targetData()
setTargetData()) and implement on the qmake project side.
Implementation for Cmake/QBS is architecture-wise possible, but
not used right now, and left for later.
Change-Id: I3bbf66170020cf9027a894cd66db15ec7ffbf499
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>
BREAKS BACKWARD COMPATIBILITY OF TOOLCHAIN SETTINGS!
* Convert old ToolChainKitInformation to new version
* Store several toolchains in one kit (one per language)
Change-Id: Ia59a2ad067c57971ec34ce9b2e43758344443755
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
Remove unnecessary constant and move others into the cpp file where
they are used.
Change-Id: Ib1e8ac69a39eb38794bbdafc860ca42ca29c3bdb
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
This can apparently get triggered with qbs projects.
Task-number: QTCREATORBUG-14493
Change-Id: Id645fbad1a0b9fdff1d1840f8ba5821b3be56b7d
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
Make DeployConfigurationFactory a true base class. Introduce the
DefaultDeployConfigurationFactory as the implementation that
actually creates DefaultDeployConfigurations.
This mostly moves code around. The virtual canHandle method was
mostly unused and was removed from most classes.
Change-Id: I170d94c648e67f3fe52a76ffb5344f389ae49efc
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
So that a name actually shows up in the "Add" drop down in the deploy
settings.
Change-Id: Ie39a1ddb5462d1b88be10d7c0ba7d19811d7970c
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
- Split up androiddeployqt into two steps: One building the apk,
and one deploying it to the device.
- The build apk step base class AndroidBuildApkStep is ihneritaged by
the qmake specific class QmakeAndroidBuildApkStep.
- The deployment step is still called androiddeployqt
- Move all qmake specific code to the qmakeprojectmanager plguin
- Flip the depencency between the android and qmake plugin, now
the qmake plugin depends on the android plugin, implementing
a interface the android plugin provides.
- Note: This removes the debug deployment for now.
Change-Id: I1c386640159ed14b637668abde8eb3b9009ab803
Reviewed-by: BogDan Vatra <bogdan@kde.org>
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>
The API was there just not the correct implementation.
Change-Id: I65468f3c00f3c8ba1b853f8c11f6296813d1a966
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
* Rename profiles to kits.
* Update some strings:
* projects mode has a Kits tab, not a Targets tab.
* " Settings" was dropped from the sub-tabs of the Kits tab
* menu entry "Build/Open Build/Run Target Selector" was renamed
to "Build/Open Build and Run Kits Selector".
* Use "Kit" instead of "Target" in miniprojecttargetselector.
(The class was not renamed as it does indeed select targets,
not kits)
Change-Id: I0727e086e2dfa0e8aaaf89fdc6f2e3596c7a4314
Reviewed-by: Eike Ziller <eike.ziller@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>
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>
