Using rsync enables proper incremental deployment and is particularly
helpful when larger files are involved.
We check whether rsync works as part of the device test. If it does, it
becomes the default deploy step, otherwise we fall back to SFTP.
Change-Id: I6ab938ccd5acd7e0cbe07b90b6938dccad19bba5
Reviewed-by: hjk <hjk@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>
It's unlikely you want to have two instances running at the same time,
and SFTP does not let you overwrite a running executable anyway.
Task-number: QTCREATORBUG-19326
Change-Id: Iac48d28f538307fc1764f973ce0c9959ef89af03
Reviewed-by: hjk <hjk@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>
Mostly done using the following ruby script:
Dir.glob('**/*.cpp').each { |file|
next if file =~ %r{src/shared/qbs|/qmljs/}
s = File.read(file)
s.scan(/^using namespace (.*);$/) {
ns = $1
t = s.gsub(/^(.*)\b#{ns}::((?!Const)[A-Z])/) { |m|
before = $1
char = $2
if before =~ /"|\/\/|\\|using|SIGNAL|SLOT|Q_/
m
else
before + char
end
}
if t != s
puts file
File.open(file, 'w').write(t)
end
}
}
Change-Id: Id48e46fdfed83b82071551f4375fab3310ed1f6e
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
These classes currently live in the RemoteLinux plugin, but there is
nothing Linux-specific about them. Adapt the class and file names
accordingly.
Change-Id: If1936265cf83afaef9e14bbb0f54ede5e054e76a
Reviewed-by: Daniel Teske <daniel.teske@digia.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>
Until now, the mapping was based exclusively on the device type. The new
approach is more flexible and less static, allowing e.g. the set of
supported devices to depend on the current build settings.
Change-Id: Iec92bdf9fee647477b166f7624c2364a821e5cbd
Reviewed-by: Christian Kandeler <christian.kandeler@nokia.com>
The idea is that all kinds of devices inherit from one abstract
base class and that they are all managed by one device manager,
who does not know about their specifics.
For now, the only concrete subclass is the LinuxDeviceConguration.
Change-Id: I31ff5586a0fdd6bcf8dcc0554bb2b91fe65b2f3f
Reviewed-by: Kai Koehne <kai.koehne@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>
