These still assumed we can only multiplex on profiles.
Change-Id: Ice3dfe06c1be732ecae42db75155e930b0554b6f
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
... with the ability to opt out, as in the qmake run configuration.
Task-number: QTCREATORBUG-19274
Change-Id: If4e996a974a82080bb09f2971b0bb5df9173fb14
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
To HEAD of 1.11 branch. Also do the adaptations necessary because of the
branch switch.
Change-Id: Ief69ef014c10397c14fcd68a9ca770d1391d5491
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Similar to 85206e216a for qmake.
Unify the lookup logic in BaseQtVersion.
Change-Id: Id0b0ff3127f0561ac36610ada16110b55252eb31
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
... including build target name and display names instead of
returning QString build target names and producing display names
via displayNameForBuildTarget()
This is a mechanical intermediate step on the road to use
Target::applicationTargets().list uniformly as source of build
targets.
Change-Id: I7b0b1fb398d5061b0cec0b86890f9eaf0bb53a19
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>
... rather than in the run config widget. Otherwise merely opening the
run settings can change the behavior of applications.
Task-number: QTCREATORBUG-19374
Change-Id: Ib227ab07d09b7a8ce34909ae0b08b6b222bcee14
Reviewed-by: Georger Araujo <georger_br@yahoo.com.br>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
This shifts the resposibility of creation/splitting of RunConfiguration
ids into what are essentially "type ids" and "build targets" to the base
implementation, possibly opening the path of abandoning the mangled ids
in favor of explicitly storing their constituent parts.
Take advantage of base id split in RunConfigurations for availableIds
/displayNameForId and for canCreate/canRestore/canClone.
Change-Id: I19fefb32757407ab5053a2ae0e5a79438659f6ec
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Filippo Cucchetto <filippocucchetto@gmail.com>
All RunConfiguration factories had some kind of canHandle(Target *)
implementation. Centralize this notion.
Change-Id: Ie24a355e857bddfd76b866859b8c7a42ffc83840
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Moving aspect data closer to real Value semantics fixes
the regression introduced by 890c1906e.
Task-number: QTCREATORBUG-19186
Task-number: QTCREATORBUG-19192
Change-Id: Ieaeef3995ae06a817f266c1e2514f9e5793bd4e8
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
After 890c1906e6, all the run configurations had generic names, because
the initialize() function did not call the base class implementation.
Change-Id: I2eff43f7c40214bcc1167d596fe2328a4b3c122a
Reviewed-by: hjk <hjk@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>
Centralize handling of enabled state of RunConfiguration widgets.
Remove code that does the same thing in all the different run configuration
widgets.
Change-Id: I175d7e19d031bd28a2b19cd825e0b6568da19bc3
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
... and use this as a base for all RunConfigurations.
Clean out code in the individual run configurations dealing with their
enabled/disabled state.
Change-Id: Icc2ea136b056f7aea7ce96480b4402459d7ac0ce
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Get rid of duplicated code to do such signaling in derived Project types.
Change-Id: I26914a1d751d72ee65c15a7943e0e7f34978f042
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
A lot of the target-and-tool specific run controls nowadays
have something like a single main RunWorker. This patch
removes the need to have user-implemented RunControlFactories
in those cases and adjusts local run, remote linux,
python and nim to take advantage.
There's more potential use downstream.
Change-Id: Ie2d2f839b8be1fad2be3b79e21de3c0e475d88cf
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This patch prepares for enhancing information stored inside
buildSystemTarget.
Change-Id: I5d81fd01ab6b06c162f47fd9536de697ddfd24a3
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
... in a modified variant. The install root is now taken from the build
step to ensure consistency.
A dedicated deploy step can be useful on Windows if one wants to rebuild
while the application is running.
Task-number: QTCREATORBUG-17958
Change-Id: I93bc59b0e6d954d61d84bcfc81576cdb4fac1216
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When the build environment was changed, the run environment widget would
not update.
Change-Id: I8a318d86b5ac56ca9233cf4c694ca3c9f88870ed
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
... in the build settings. This makes it much easier for users to
properly set the installation directory. In turn, remove the dedicated
install step, which does not know about qbs.installRoot and has not had
sensible functionality ever since that property was introduced.
Task-number: QTCREATORBUG-17198
Change-Id: Id968672f4365e75da437f73ec15bb5e32599bda3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Introduce a method that maps a RunConfiguration to the build system target
that created the executable.
Implement the method in all RunConfigurations where that makes sense (e.g.
no CustomExecutables).
Change-Id: Ifaac859c2cd9b2806a0d7c185b2239312a67752a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
To HEAD of master branch. Also do the necessary API adaptations in
QbsProjectManager.
Change-Id: I4709b7a0f35537f5b6f9fd04f4d95be16aef2c8d
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
This way we can use them from libraries, not only from plugins.
Change-Id: Ic35cfd5f04d638d87606bf272b2c00ded1267c1b
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Before accessing qbs::Project methods, we need to check whether this
object is valid.
Change-Id: I6c54f5b1118a3960b4814af647d81f5786fa452d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
... by default.
Similar to qmake qtc_runnable.
Apply in app.qbs.
Change-Id: I8d43027f683ef18fc5a2745afe9775eb14075e69
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
And adapt to API change.
Task-number: QBS-952
Change-Id: I668d6830187f7954e7391f09ff8522422fd0d44d
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
LocalEnvironmentAspect needs to take care of being cloned.
Task-number: QTCREATORBUG-15700
Change-Id: Id040a2a150dbc1cd3e407aa3d7dfc2728d7bb3db
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Sprinkle overrides over code derived from classes in ProjectExplorer
Change-Id: Ia4cc25649f7dc00b0ea126d8176a59afbc5ed574
Reviewed-by: hjk <hjk@theqtcompany.com>
The functionality can be provided by producing a suitable Runnable
in the derived classes directly.
Change-Id: I7b8e8fe33fffd2b00176b6cf6633eca4e152e466
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
+ use native separators for user visible strings
Change-Id: Id6e4e27db369314f70e355a395cfddca12b8ea90
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Instead of describing icons via file name or in the themed icons case
via
a string that is a list of mask/color pairs, we have now a class for it.
Icons are now listed in per-plugin *icons.h headers.
RunControl::m_icon was The only place left where an icon property was in
fact a string. This patch changes that member to be a Utils::Icon.
Change-Id: Ibcfa8bb25e6d2e330c567ee7ccc0b97ead603177
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Commit 2dbc5b1032 introduced usage of WorkingDirectoryAspect into the
qbs run configurations for Desktop targets. However, the design of that
class was not suitable for the way our working directory logic works:
There typically is a user-provided value and, as a fallback if the user
does not provide anything, a default value managed by (build system
specific) code. The WorkingDirectoryAspect class could not differentiate
between these two values and so the value stayed forever at the initial
default if the user did not override it, instead of adapting to the
location of the executable.
This patch makes the necessary changes to the WorkingDirectoryAspect
class so that it matches the actual use case.
Task-number: QTCREATORBUG-14891
Change-Id: I7555d0a9cb4b04b75c9215a988278db32eb1ca10
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
The "executable" field in the local run configuration widget stayed at
"unknown" directly after a build, because the widget was not informed of
that information being available now.
Change-Id: Iadd86ad3d36250f5a54277707fbf1d8bd2df1232
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
