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>
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>
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>
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>
It's only used once to check whether there exist at least one.
Since there's always the DefaultConfigurationFactory when the
ProjectExplorer is present, this check will always succeed.
Change-Id: Id457701bd6c8f68b91a0e225507181a878faac4a
Reviewed-by: Christian Stenger <christian.stenger@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>
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>
Get rid of Project::buildDirectoryChanged signal as well as
Target::buildDirectoryChanged (and the infrastructure).
Change-Id: Ia749e62eec7e182e558d81115dc2a3d07b72b346
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Add a subscribeSignal method to targets and projects that will make
sure all signals of all project configurations added during the lifetime
of the project/target will get connected (if the type matches).
Use this to connect to some signal in all BuildConfigurations of
a project and get rid of code that keeps connecting to the current
build configuration.
Use Project::buildEnvironmentChanged as an example and convert its
usages.
Change-Id: I689bcebac4b191bf3f8a18765bf18eaac371c5fe
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Add ProjectConfiguration * to activeProjectConfigurationChanged signal on
Projects and Targets.
Change-Id: I56f71e034eacaaa043b19c7fd5d82e6c5ea58517
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Returns true if the ProjectConfiguration element is currently active
and false otherwise.
Just a convenience method.
Change-Id: If75809ae7e78149d264deaaf6adc4ca8a8be43c2
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Enable support for tooltips in MiniProjectTargetSelector. Use it to display
the kit information when hovering the Kit selection area.
Change-Id: Ie9691973cb74e25217635dc0a798dd9c6219ad37
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Use std::function instead. Clean up API while at it.
Change-Id: I6e401ab57f5375e36710c30508c596af3f4b3385
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This makes the code a bit simpler, at the cost of the factories not
having access to the fully specialized RunConfiguration anymore. This
is apparently never used and the factories can still use the Id to decide
what to do if they really need to.
Change-Id: I7d94f85e984ac87e62c6d341c1038e1538aa15df
Reviewed-by: hjk <hjk@qt.io>
Device status overlay and the device status display should be two
separate icons. This change makes it happen.
Change-Id: I3a965fdb8b74c447a5cf80e4c90a3ae06c91b3bc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Handle buildsystems with imperfect knowledge about what they
build more gracefully.
Leave RunConfigurations around if the build system can not tell
whether or not the relevant target was configured out of the
current build or completely removed from the build system.
This patch should not change the observable behavior of the code.
Change-Id: I0ddb4bd3966d184a4b5c9818e68adb107047ed1f
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
Make the slots private now, remove protected as nothing inherits
from Target.
Change-Id: I4aaa4402ef6ee83a27dd6233f188a507e9de8169
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
This is far from perfect but seems to work. Further work could add more
fine grained control over which projects are affected by the automatic
synchronize. Also there might be a few cases where the switching is
over zealous or missing.
Change-Id: I26ad3d59431251564917e4b408c66695dc454823
Task-number: QTCREATORBUG-5823
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
BuildConfiguration asks Target,
Deploy and Run ask either activeBuild, or Target.
Change-Id: I3845cfbd16de7b85268d83b5324865ff24482152
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
This was a regression introduced during the macro expander rework.
Task-number: QTCREATORBUG-13260
Change-Id: I9fd28c6a522faa11992931f937dd0b0eb779f419
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Takes a member (function) pointer and a value and returns a functor,
that takes a instance of the mfp's class and returns whether it's equal
to value. Sounds complicated, but is a common pattern that is easy to
understand.
Change-Id: Iaaeb90488d34ddfd6940dadd4c66705381198fee
Reviewed-by: Nikita Baryshnikov <nib952051@gmail.com>
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Add Utils::transform and anyOf that take a member function pointer.
Remove bestElementOr it's unused.
Use declval<T> in transform's return type, because msvc does evaluate
T() and for types that don't have simple constructor this fails.
Add std::remove_reference since decltype returns a reference for
lvalues.
Change-Id: I22248b226748eeb27af0d300182d574438d7f756
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Together with the previous patch this avoids recreating RunConfiguration
widgets for RCs which are about to be removed because they are no longer
valid.
Task-number: QTCREATORBUG-10248
Change-Id: Ia8e394175c1cdef469faa8d117a2736500d928e4
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
... use the current kit name instead (in case it was renamed since
saving the project).
Task-number: QTCREATORBUG-10401
Change-Id: If329d3441eb27a4322cb346849e4b73296d5bf88
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
Generalize the target setup page and move it into projectexplorer
Move the qmake specific code into a projectimporter class with
a specialization for qmake projects in the qt4projectmanager.
This change depends heavily on the BuildConfigurationFactory cleanups
done earlier and completes that change in such a way that generic
build configuration factories are now in theory possible. The
remaining problem is how to select the best factory of several that
claim to be able to handle a kit and that is left for the next patch.
Change-Id: I47134cb1938c52adebcdc1ddfe8dbf26abbbbeee
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Refactor the code of the build configuration factories. The idea is to
generalize the code so much that we can allow plugins to install
custom build configuration factories for the platforms they support.
To support this use case the following changes where done here:
* BuildInfo class was introduced to describe one build configuration that
can be created by a factory.
* Factories report a list of BuildInfo to describe what they can produce.
This fixes the need for factories to implicitly create one buildconfiguration
and then create another one 'officially' to support debug and release build
configurations to be set up for projects.
* Do no longer work around factories to create build configurations.
Change-Id: Ic372e4a9b5c582633b467d130538948472b89d91
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
