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>
Allow multiple expanders to be registered for lineedits, e.g. a
local and the global ones, and actually show them.
Use a tree view in the chooser for somewhat more structured display.
Change-Id: I769f92144e5249f45e54381de52aa6973eb20118
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
So that in the context of the buildconfiguration and its buildsteps
current project and others refers to the project of the bc.
Task-number: QTCREATORBUG-12869
Change-Id: Idad7741301432a5fddffdff4225762f4100a3dee
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>
Currently we pass in some places by value, elsewhere by const ref and
for some weird reason also by const value in a lot of places. The latter
is particularly annoying, as it is also used in interfaces and therefore
forces all implementors to do the same, since leaving the "const" off is
causing compiler warnings with MSVC.
Change-Id: I65b87dc3cce0986b8a55ff6119cb752361027803
Reviewed-by: hjk <hjk121@nokiamail.com>
The find methods should not return a factory with a -1 priority.
Change-Id: I05dab0c48b24b30f88cf40f49c2bc0e24bff46ec
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Makes test_modelmanager_extraeditorsupport_uiFiles pass again. Before, a
"CMake Wizard" dialog blocked the auto test due to the wrong
comparisons.
The std::max_element function takes a less predicate. Thus the right way
to find e.g. highest int in a vector is:
std::max_element(..., std::less<>) or
std::min_element(..., std::greater<>)
Both variants are confussing to read. Instead of provinding
Utils::maxElementOr provide a bestElementOr which leads to this code:
bestElementOr(..., std::greater<>).
Change-Id: Ic30f0d742c03170b28227f60d3a5ae00e40fdf5a
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
