This is getting repetitive.
There's a new connect too, that's not wrong in the current two uses
and will be helpful in the upcoming Qbs one.
Change-Id: I4a4923a43937922c66be1f73822103b1e3e7b077
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Just for the "storage" part with this change. Plan is to also
use the gui parts one-by-one in the BuildConfig reimplementations.
Change-Id: Ie5e4e701eea8d83336103654c708f4f1ab8132e8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Mimicking the other aspect-unsing setups. It is currently re-implemented
in all derived classes, i.e. unused.
Change-Id: Ia1c16318347baa13a869d3eb03717a0f5ff0d8f8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The name "KitInformation" does not properly convey the fact that it
represents a certain *aspect* of a kit. The same goes for
"KitConfigWidget", which in addition was inconsistent with
"KitInformation".
We now use "KitAspect" and "KitAspectWidget".
Change-Id: I9804ee4cedc4d61fad533ea1dd4e4720e67fde97
Reviewed-by: hjk <hjk@qt.io>
QDir::cleanPath() must be called on the expanded path, otherwise it
messes with the data. For instance, QDir::cleanPath("%{a:b}/..") yields
".".
Change-Id: If55b9c7a733097cb36f62fbdae49fe03b542fcdf
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It's essentially an intrusive hack that's used only to prioritize
Ios+Qmake over plain Qmake. The effect is now achieved by an
arguably equally evil dependency on the construction order of
BuildConfiguration factories.
It can be argued, however, that this is a feature as it allows
user plugins to intentionally override core functionality by
using the standard setup pattern and depending on the to-be-
overridden plugin.
Change-Id: Ic1efa305daf3ca19a880d2a7ccb40e2768d8f57c
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... also for BuildConfigurationFactory, similar to Run and Deploy.
Change-Id: I453f08bf145d6a2e764d150646c698d624ae2ce9
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... to pass it around as real values, avoiding, among others,
the need of occasional explicit deletion.
The formerly extra members of the derived stuff are handled via
an extra variant (for data) and via a functor in the build
configuration factory.
The change is mechanical.
Change-Id: I19ca4e0c5f0a5b196fc16dfb98bb005dc679f855
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... to BuildConfigurationFactory. It hasn't been an Interface for a
while and the new name matches Run- and DeployConfigurationFactory
Change-Id: I923c6a27e18a99628251b69e0270e910836e7b2a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This makes e.g. %{CurrentProject:VcsTopLevelPath} in the kit's
environment much more useful.
Task-number: QTCREATORBUG-20752
Change-Id: I4bf49e61a7a7281a6c9bf039a1d9118b6e4060ef
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
That's effectively a generic hook for "re-run qmake" without the
qmake/QmakeProjectManager dependency.
Change-Id: I236d40690cde9047831422b2651ed2284b220959
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>
Following the RunConfigurationFactory lead this replaces
f = Foo::find(); f->do() by static Foo::do() stanzas.
Also de-virtualize/private-ize IBuildConfigurationFactory::canCreate()
as it is only a local helper nowadays.
Change-Id: Id36ba514f426ebd054592189aa29c170ba00d92f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Fixup after 45d6a34f: An empty list of target device restrictions
means 'no restriction'.
Change-Id: I15773e75e58c3ba543d62e13d728cf08dccc3650
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Check the supported devices and return the base priority set by the
factory implementation
Task-number: QTCREATORBUG-19573
Change-Id: Ieae68a618d625b3f16f205e544f4626e6a410b91
Reviewed-by: hjk <hjk@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>
Set up a better environment for initial project parsing (before Kits
are configured).
Task-number: QTCREATORBUG-19241
Change-Id: I2431113dbbe6fb6a66f95fb1efb36834fa184f3d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Macros in build directory were not consistently expanded, so building
failed (at least in qmake projects).
Task-number: QTCREATORBUG-18601
Change-Id: I7ab06a1b969866748cf4062d1c820e5830efe281
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Make it clear that emitEnvironmentChanged also updates the cache of the
current environment.
Change-Id: I012c5a2b3d7d4037ed609b26e053ce0ce36f6cec
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Do not unconditionally prepend the (c++) compiler path to PATH for
all projects using GCC-derived toolchains.
Prepend the compiler path in the Qmake- and GenericBuildConfigurations
instead.
Also change the order: Apply buildconfiguration's addToEnvironment first,
only then apply the kit's addToEnvironment.
This does change a few things:
* CMake and Qbs will now get the normal PATH
* MSVC compilers will have their compiler path prepended to PATH
by the effected BuildConfigurations. This should be harmless,
since that happens before the environment setup script is appended.
Task-number: QTCREATORBUG-18714
Change-Id: I548182bc447d80d24f4de4ce7cf12ee1a753ed26
Reviewed-by: Eike Ziller <eike.ziller@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>
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>
Make BuildConfigurations provide %{CurrentBuild:Env:VARNAME} via the
macro expander infrastructure.
Change-Id: I1bed8c6aa9003c361a07fa69a5a3840f7a4e0d17
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
It's not really needed. The Null-ness is equivalent to a failed
fromMap() which we execute on all usage paths anyways.
Change-Id: I72bb7fb55b7f26680fa68da8eef751ca96380ecd
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use that helper in the projectexplorer instead of hardcoding a mapping
there.
Change-Id: I8720607a869c086569661fc9e9326ed6e0f85bb3
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
Introduce the class AndroidQmakeBuildConfiguration whose purpose is
to set the environment variable. Modify the Factory to create
buildconfigurations of that type and fix restore/clone to also
take the factories' priorities into account.
Change-Id: Icb377fa9211cd3564c36b60cf7c5f7dd84fcab50
Reviewed-by: BogDan Vatra <bogdan@kde.org>
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>
Some derived classes already had one, at times.
Make it uniformly accessible in the base class.
Change-Id: Iccb7ebf9d163daba46a01ae5de150af4a883fad6
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
All static functions, can live closer to related code.
Change-Id: I54c5680256c78f1d09b4bee3e8843b2f4350b75a
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Make const-correct, add convenience function for commandline parameter
expansion.
Change-Id: I12c3651e4e7b8a0a9319d1dfbea676b622b1a41a
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
