DesktopQmake, CMake, Qbs, Nim, RemoteLinux and Qnx now have a common
understanding what should be in a runnable and how their
configuration widget should be set up. So move them over to
using shared code, too.
Several others runconfigs only lack a one or two more aspects
to follow suit in later patches.
Change-Id: Ia862c95c97d63bd0a0f2dc303435775a2fc530d3
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Report project-specific warnings about the kit used in Project Mode.
E.g. a python project should not complain about missing toolchains,
while a qmake project should.
Change-Id: I5ce6742683cdeffc7ff3f1a3e8f0b89aee9aa0b4
Reviewed-by: Thomas Hartmann <thomas.hartmann@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>
The previously per-Project/RunConfiguration changing meanings of
BuildTargetInfo::buildTarget have by now been split
into separate values in BuildTargetInfo:
- buildKey a handle to one item in Target::applicationTargetList
- displayName a user-visible string in the run settings page
The buildKey was tweaked to coincide with the previous 'extraId',
i.e. the non-RunConfiguration-type part of the project configuration
id that (still) use id mangling.
This allows replacing the cases of locally stored seven different
versions of buildKey(-ish) data by one RunConfiguration::m_buildKey,
and do all remaining extraId handling in RC::{from,to}Map only,
i.e. remove the base ProjectConfiguration::extraId() virtual and
remove the "re-try fromMap with mangled id" hack entirely.
The id mangling is still used to temporarily maintain .user file
compatibility in some cases for now, but should be replaced by
storing the build key and the RunConfiguration type soon. Qbs
already changes in here to only use the uniqueProductName as
buildKey, without the previously added display name which is
stored as part of the ProjectConfiguration already.
It turns out that RunConfiguration::buildSystemTarget was intended
and used to retrieve an item from the Target::applicationTargetList
for some configurations, coinciding with what buildKey does always.
So use that insteand and drop RunConfiguration::buildSystemTarget.
There is clearly is further consolidation potential left.
handling of (default)displayNames is still a per-runconfiguration
mess and there is further consolidation potential left.
Change-Id: I448ed30f1b562fb91b970e328a42fa5f6fb2e43e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Margins and layout style widely differ so far. Start moving everything
to a QFormLayout with the same margin and growth policy.
Change-Id: I0bd1d8b2ec9830be56354be1376a2a24eebb8845
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Some translations moved over to the corresponding RunConfigurations,
one setParent() replaced by direct deletion.
Change-Id: Ib5e527b71353a6be70b332ac2dfd2f5cd2499a60
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
canHandle() is only used locally in the implementation, so
make it private and de-virtualize.
canCreateHelper() did nothing except returning true anymore,
so remove it.
Change-Id: Ifac39e077e3c296b2b2dfc9fbb29c20884e056a3
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This removes the outermost layer of widget-vbox and moves some
common code into a helper function.
The pattern repeats (with variations) a few more times, that's
left for later patches.
Change-Id: I8c98229cf41d03d5330c896ec9fa0965bfc65602
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Change-Id: I0ba784a4d775730277ec0b21aef649011f37b739
Reviewed-by: Alexander Drozdov <adrozdoff@gmail.com>
Reviewed-by: David Schulz <david.schulz@qt.io>
Physical existence of a file is not strictly needed for something
being runnable, e.g. 'foo' can be used to start a process on windows,
even when only 'foo.exe', but not 'foo' itself exists.
On the other hand, the existence of the file is not sufficient either
to run it, so the check was too weak and too strict at the same time.
Change-Id: I4a41d2f5cbb0cb471023a8bc23628072b28a5984
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
Funnel all relevant data through target.applicationTargets() as
done for the non-local CMake-supporting setups and QBS already.
There is cleanup potential left for later changes.
Change-Id: I49ed6abd98c058a7fd1545e41b3bcd6ecb758a8b
Task-number: QTCREATORBUG-19985
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
A for (f : X.allFs()) if (f.canHandle(t)) { f.doIt() ... } }
pattern can be replaced by some static X.doIt(t), and
item.factory->create(target, item) by some item.create(target).
Change-Id: I65df8b71e03272d60f41a16795ea43a0fdb262ef
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This is unused here by will be used in subsequent changes.
Project parsing yields information on whether there's a console
requested and whether the "magic" qtc_runnable flag for primary
executables has been seen.
Also, the current "targetname" is taking different roles in
different context, try to split-off the pure visual aspect
by allowing to specify an explicit displayName, with fallback
to the current decorated targetName if empty.
Task-number: QTCREATORBUG-19985
Change-Id: I11edfcaafd17972f6a78aeff3fbbf3d7eb91a213
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It's not an *I*nterface anymore
Also, remove the in-all-but-one case unused QObject parent and the
object name that was only there for debugging purposes. The class
type serves the same purpose in the debugger.
Change-Id: I0dafb01e6b4fd7c7df04a63aaa3ef3e4bd693f6f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This was a debugging aid, not needed anymore.
Change-Id: Iaabd33eb5f821dba45a3e39aa058838f3b9359a2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... at RunConfig Creation time. This eases the id mangling case.
Use it in the PythonProject.
Change-Id: I9a7e2c90997ed5ab737cd4fa68895217bdbe1dfe
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The struct will likely gain qtcrunnanable/terminal members,
better pass all to where it is needed.
Change-Id: Ieb0dae8b56ce5c0992955dbfc0cd89cdd7bfe848
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Move some code around to make interfaces slimmer.
Also no need to check canHandle() twice per creation.
Change-Id: I7c86e2dc78ebd53a0f8e9609e9fa135aaf31e7b7
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It has been used twice on each Target::updateDefaultRunConfigurations():
Once to help filter out potentially interesting factories, and then
to actually retrieve the creators from the interesting factories.
The same result can be obtained with less effort and less code.
Change-Id: Ic83423bbbc172c842ec5a55fcd6ad83106e268aa
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
In line with addSupportedProjectType, saves a few cycles due to the
non-use of the temporary list, and in theory more flexible than the
existing set...(QList<Id>) as it potentially allows dependent plugin
to declare support for already existing configurations instead of
re-implementing their own.
Change-Id: I2b83e90de49daa9bfce6f780c5f51c2e971eb7d1
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
So far we used device type in some cases, not even following a specific
pattern.
Showing the device name gives a bit more detail in cases of multiple devices
of the same type and offers the user a bit more control on what it shown.
Change-Id: I2bd6bbd404577db3afca0f84b8a976cb07b1cfd0
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Instead of calling twice for AutoCreated and UserCreated, call once
and record to which case it belongs. Only the 'both' and
'user only' combination are ever used.
Change-Id: I9c15085bcbb4bf6584a6156135f2084dbfc51c1c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This was previously intented to be used in the RunConfig Add... menu,
but this role is now taken by RunConfigurationCreationInfo::displayName.
This fixes also a regression for setups that relied on
QmakeProject::buildTargets() and a fix up empty display names later.
Change-Id: If75fc79efbdedc918a126e50c962fc188d7a3ebc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This was already almost the desired final pattern, so make it the default
implementation of ProjectRunConfigurationFactory::availableBuildTargets.
For the only remaining feature of "decorating" the build target names,
introduce a property m_displayNamePattern.
Un-adapted sub-classes still need (and are able) to overide.
Change-Id: Ia7d2d2f7d53f8b1da487fa82c8265ad5deb47500
Reviewed-by: Christian Kandeler <christian.kandeler@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>
To be used for "special" build targets (Custom executables etc) that do not
depend on the project. This reduces user side boiler plate in a couple of
cases and is a bit clearer than the magic {QString()} result anyway.
Change-Id: I105b6ab952981143b2abf9b218fed30cee80b648
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... by additionally keeping local (currently non-owning) pools per
"interesting" type.
Current situation:
- The global object pool does not scale well for looking up
objects, as iteration plus qobject_cast typically iterates
over all pooled objects.
- User code that can use typed results from the object
pool need to have access to the full type definition anyway,
i.e. depend on the plugin of the target class anyway.
The patch here solves the scaling problem is to have local
type-specific pools to which objects register in their
constructors and deregister in their destructors.
This patch here does *not* change the ownership model of the
pooled objects, however, it opens the possibility to change
the ownership model per type (e.g. by not putting things into
the global pool at all anymore and make the local pool 'owning')
and the intent is to handle that in later patchs.
Even without the follow-up patches this here is a performance
improvement for the cases that access the local pools instead
the global one, i.e. "practically all".
Change-Id: Ib11a42df2c4ecf5e1155534730083a520dd1995b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
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>
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>
Do not add newlines when output gets flushed.
Task-number: QTCREATORBUG-17403
Change-Id: I0dea3a15611fcde8aa8cbc5fbc6b7f22c9c40dd7
Reviewed-by: hjk <hjk@qt.io>
All RunConfiguration factories had some kind of canHandle(Target *)
implementation. Centralize this notion.
Change-Id: Ie24a355e857bddfd76b866859b8c7a42ffc83840
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The pointer passed in was assumed to be non-null, but that does not need
to be the case.
This should make the function more robust in face of errors. The RunControl
passed into the method is taken from a QPointer. So if the RunControl is
destroyed, that pointer may be nullptr.
Task-number: QTCREATORBUG-19269
Change-Id: I42e7b9d5582df2ee0830c8f92af4e4a97e7d6417
Reviewed-by: Eike Ziller <eike.ziller@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>
It's not meant to ever change after contstruction.
Change-Id: I912b58dfb70b40c9763b902650d2c657c28ccc5c
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
For targets such as remote Linux, we would run all run configurations on
the remote device, even "custom run configuration", which is explicitly
intended for running locally.
Task-number: QTCREATORBUG-19121
Change-Id: I83d6bdd8a47440047d230266845286715432604a
Reviewed-by: hjk <hjk@qt.io>
The exectuable path in the user output was always converted to native
separators, even for non-Desktop targets.
Change-Id: I5b43b2da8a2b791472a1fd58940b179dcbaa28d0
Reviewed-by: hjk <hjk@qt.io>
Useful in some more complex setups.
Defaults to the tradionally unconditional reportFailure().
Change-Id: I26acaace1fa1e12caf83b785e4be539d8af7eb73
Reviewed-by: Filipe Azevedo <filipe.azevedo@kdab.com>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This moves the explicit build step into a dependent runWorker,
making the whole setup more aligned with a normal tool run.
Change-Id: Icd01b2e82f7f95774434d2ede04d08a5311b64e7
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
