It was already only one id string with two names. Since it is not
an id for the factory but the id of the created run configuration,
settle of runConfigurationId() as accessor.
The factory and id fields in RunConfigurationCreationInfo were
redundant. factory always implies (runconfiguration)id (but not
necessarily the other way round, in theory different factories
are possible for the same runconfiguration type for different
devices). So drop the id field here.
In one case now factory pointers instead of ids are compared, but
this is neutral there as this happens in a context of a fixed Target,
device and project are fixed there, so id and factory are equally
unique.
Change-Id: I859aa91486a2dd4abfc7369540a3322d6ec6260d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This combines two of the previous three paths to create run workers,
and refers to RunConfigurations by id, not by type where possible
to decrease coupling between the classes.
Only allow "type of run configuration" and "type of device"
as the only possible kind of restriction and require a uniform
RunWorker constructor signature.
Adapt user code to fit that pattern.
Change-Id: I5a6d49c9a144785fd0235d7586f244b56f67b366
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
For some reason, Q_UNUSED includes already a semicolon, adding one
on the user side creates an additional empty statement.
Change-Id: I9c5e8fac381345a60792cb75e2938fd53958d3b0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Same result, less code, more fashionable.
Change-Id: I43b0fcc6e5efb5e394b1652c3c9b34871cbe2fee
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Except for the DesktopDevice, which is kind of special. Also try
a bit to make (and partially fail at doing so) naming and code
structure (#include, use of namespaces) more similar to each other.
Change-Id: I9fe266e706b72c14f59ff03ca1ae02dba3adcc71
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This removes the IosPlugin::kitsRestored() member that does not
fully fit the standard plugin implementation pattern.
Change-Id: Iedd79e5326b85b189673c19e1920e21c34cd03bb
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Instead, set the default level of all logs to QtWarningMsg.
The call to setFilterRules overrides the user preferences in qtlogging.ini.
Change-Id: Id5f6cd550d14ff7f45ae04c5d3110e0bafb0f072
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: hjk <hjk@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>
Also generally follow the current plugin setup pattern,
remove unneeded uses of global plugin pool, move stuff
to the usual initialization phases.
Change-Id: I1eb1d8251be68aa095e07125d42451dae4a3dd06
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
It was all done in one huge, unreadable method.
The refactoring along-side fixes the following:
- iOS tool chains were demoted to manual at start up because there
was no tool chain factory that would auto detect them
- a QTC_CHECK failed because single Qt Versions could appear multiple
times in the architecture->Qt version map, because each architecture
is present in two abis (32-bit and 64-bit)
The refactoring also removes unneeded automatic conversion
from non-iOS Qt version to iOS Qt version, and removes considering GCC
toolchains (which were not handled anyhow, because only Clang
"platforms" were considered).
Change-Id: Ic9ae797646f159ed45959fc797990aa98f2136fb
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Remove usage of the Q_EXPORT_PLUGIN macros, which do not exist in Qt 5.
Change-Id: I678c3cf10b9c5d5c1b9f252b0ecd1c97dc810a47
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
The lldb debugger sometime returns misleading debug information
unless a dsym has been created.
This creates a build step to do it.
Task-number: QTCREATORBUG-11580
Change-Id: I7acf2e539cf189d0237e1d502fab2837f17aa489
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
Use just one xcode, namely the one of xcode-select (like qmake)
cleaned iosconfigurations:
* cleaned now unneded xcode paths
* using static methods, removed IosConfig
Change-Id: Icc4d1bc1063a5f65230736a47b4ca9b139fa79e0
Reviewed-by: hjk <hjk121@nokiamail.com>
The modal dialog was opened directly from the tool output processing,
and when returning the tool handler was already deleted.
Change-Id: Iacba584b59bf8720788ac03fd2e839c5e4485ab3
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@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>
