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>
They would claim that a variable that has an empty value is not a valid
variable and should not be replaced with that empty value.
Change-Id: I5ee9b950b611f8878efe2f86ac5b219d51194d48
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
It was just a shortterm hack for RC1
This reverts commit e4d800ad4a.
Change-Id: If4471a8e040c7f9517551914b092b7ad0cd6d1d7
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Introduce priorities for build configuration factories. This way
plugins can register specialized build configuration factories, that
e.g. can provide additional build steps.
A negative priority signifies that a factory is not prepared to
handle a request, the default build configuration factory shipped by
the build system plugin will report a priority of 0. Add 100 to that
for each specialization you add (e.g. a remote linux buildconfiguration
factory would report 100, a specialization of that for mer will
should report 200, etc.).
Change-Id: I141a7a5a79166afdb7657d46eb7e86bd18d3abf6
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Michal Klocek <michal.klocek@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>
Use setBuildDirectory() in the different BuildConfigurations instead
of reimplementing that over and over again.
Change-Id: Ic355fdb4624c71667ce470b3e2865c9a8722ef09
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Add a include for QtDebug elsewhere where this include tended to add this
implicitly.
Also remove a using namespace directive that is unused and no longer works
since the namespace is no longer defined due to the removed include.
Change-Id: Ic216127a96c8aa11366defa0397f934d5a735925
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Indicating that new widgets are indeed created.
Change-Id: Iccc5e1e99f536fdfb0718f252a23f498053ad3a3
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Which simply returns a BuildEnvironmentWidget. A long time ago
BuildConfigurations had no environment, nowdays they do. So it makes
sense for all BuildConfigurations to have the BuildEnvironmentWidget.
Change-Id: I824c45df79a0dcd2b624bf67a4730fb5dab098bc
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Not just qt4 and cmake but also generic projects.
Change-Id: I4a7e86fb2dbf6c6e32b4da78953ad3199c554470
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
