... or Target.
This patch moves build system from conceptually "one per project"
to "one per target (i.e. per project-and-kit)" or "per
BuildConfigurations" for targets where the builds differ
significantly.
Building requires usually items from the kit (Qt version, compiler,
...) so a target-agnostic build is practically almost always wrong.
Moving the build system to the target also has the potential
to solve issues caused by switching targets while parsing, that
used Project::activeTarget() regularly, with potentially different
results before and after the switch.
This patch might create performance/size regressions when several
targets are set up per project as the build system implementation's
internal data are duplicated in this case.
The idea is to fix that by sharing per-project pieces again in
the project implementation once these problems occur.
Change-Id: I87f640ce418b93175b5029124eaa55f3b8721dca
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This hides the explicit use of a QFormLayout from the aspect
interface in a new LayoutBuilder class. That currently works
only on a QFormLayout in the back, but opens the possibility
to use e.g. a QGridLayout as use on the Kits and some option
pages.
The aspects now only announce sub-widgets they like to add,
actuall positioning is does by a new LayoutBuilder class,
also cramming several widgets in an hbox in the right column
of the QFormLayout is done there.
Change-Id: I2b788192c465f2ab82261849d34e514697c5a491
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Previously, AndroidManager::updateGradleProperties operated always
on a project node found using target->activeRunConfiguration()
which might or might not be the one that will actually be used
after the build.
This here still does not address the problem that the activeRunConfiguration
may change but introduces a way to specify the relevant node, and tries
to use the right one when available.
At some time, this could be developed into a real solution, e.g.
by invalidating the cache on build key changes.
Change-Id: I37a3d73e9ad3615025e4def2493f683d11add3c6
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Essentially following the scheme used for the various project
configurations. This makes it possible to construct OutputFormatters
by Id only, potentially reducing hard plugin dependencies and
opening the road to have several output formatters per
RunConfiguration/Outputpane/...
Change-Id: I4b5fb6fb6be8b0d9a0859f178bb0effc3398b09e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... at least logically a bit more into hunks responsible for
one of the possible choices of base environments.
This makes it possible to move code that modifies individual
cases closer to the only place that uses it.
Change-Id: I1c87bb869e04e44b92ff097b0bf25274f93808be
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Will help to streamline *EnvironmentAspect constructor signature,
which in turn will help to have a generic cloning mechanism to
clone aspect data, which in turn will help to finally execute on
the idea that RunControls should be re-runnable in their original
setup and also resilient to changes in the setup while they are
running.
Change-Id: Ibdaca487c1f7ce043e675fd014fe923a70273639
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The formerly handled special case of a missing project file is
now handled by the base implementation.
Change-Id: Ib3f7d295395b5c406acbd8bdd578fd7190b34dae
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... and adapt constructors to not take the now-unneeded
RunConfiguration pointer.
Change-Id: I53ff338f51334ff7b0c22d4bed92bfcfc8225ea7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This patch gets rid of soft asserts regarding empty history key
and a warning when trying to store these into the settings.
Change-Id: I64440ebe7ae1fca660a1dc66a1646da5d17798bf
Reviewed-by: hjk <hjk@qt.io>
We have nowadays two ways to pass data from run configurations to
tool that do not require intimate knowledge of the sender:
1. Using RunConfigurationAspects, accessible for all workers in a
RunControl
2. Using RunWorker::recordData for an individual worker.
This removes the need to use specific fields in a runnable and
means that a tool plugin can be better separated from target plugins.
The approaches are not mutually exclusive, both use an string-ish
id, I chose here to use the same string when using both.
This patch here uses approach 2. for the GammaRay/Android combo.
It also fixes a (harmless) typo (s/POSTSTART/POSTFINISH).
Change-Id: I4048693ca73b17253a39bfcacc9e1880ecf25736
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
The base AndroidRunConfiguration as such is buildsystem agnostic now,
it is, however not usable with other buildsystems as the apk build
step relies on qmake specific information, so the run configuration
factory stays on the buildsystem specific side for now.
Change-Id: I00538846028cc060aceea15ffd2e63068450f1e8
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
Note that the concept of a single monolithic OutputFormatter per
RunConfiguration (and why RunConfiguration, not RunControl to start
with?) is unchanged and suboptimal as one cannot easily combine
existing use cases, e.g. Python_and_Qt.
Change-Id: Ibeb8191020387324f22ed313230293597f96e36a
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>
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>
Let user specify list of shell commands to run before app starts
and after app quits.
Change-Id: I9794fb96180530ca6c28ce6581fda51a25be28d4
Reviewed-by: hjk <hjk@qt.io>
This moves all of the RunControl implementation into a single
RunWorker, not yet splitting it up into separate RunWorkers
which is the final goal of this series.
Change-Id: I7373105603505aa4fffd7fe5ff0145f0128b34bc
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
- allow the user to choose the visible log levels
- allow the user to choose which activities/service(s) logs are visible
- wakeup the device (API 20+)
- use only the most recent logs (API 21+ add "-T 0" to logcat params)
- use logcat -v time format, which is the same on all Android versions
In the future we can even allow the user to choose which parts of the
log line are visible, e.g. time, log level, TAG, PID, Message
Task-number: QTCREATORBUG-16887
Change-Id: I07ce00aff59a479660f5ac6da75eef973ba3f627
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
The plan is to eventually move the qmake specific class into the
qmake plugin.
Change-Id: I5653c45ed88b1be296f4963ab4117bbfa791fb85
Reviewed-by: BogDan Vatra <bogdan@kde.org>
Make it possible to create multiple AndroidConfigs so that we can have
a different one in the settings dialog from the global one. Move pretty
much every method from AndroidConfigurations to AndroidConfig, so that
the settings dialog can work with its copy. Also add some additional
logic to the settings page around the java setting. To start the avd
manager we need both a sdk path and a java path. Also do some basic
additional checking of the java path.
Task-number: QTCREATORBUG-7724
Task-number: QTCREATORBUG-10936
Task-number: QTCREATORBUG-10937
Task-number: QTCREATORBUG-11059
Task-number: QTCREATORBUG-11218
Change-Id: I148c69b9c98a8a070d17d9b0e223d01db1750e69
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
This affects mainly Apple's version of GDB. Mac users are advised to
use LLDB, or some recent build of FSF GDB.
Change-Id: I6a7fbb591e79f737e12d08b0e881e9e4d1d9660c
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Disable the runconfiguration if the project could not be parsed.
Change-Id: I979315b5e38fd1d8674da68289e021e014070c54
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Creator now realiable creates one toolchain for each toolchain found in
the ndk. This no longer depends on any qt versions being present.
Also the gdb command and gdb server command are moved to the Kit and are
no longer found in the Android Options page. Both settings can be
autodetected from the Kit options page. Note that this might break
existing android kits.
Change-Id: I1dce084f2bb372e615e19b1c9e3a1e205b5d9647
Reviewed-by: BogDan Vatra <bogdan@kde.org>
* 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>
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>
