To check this still works I used a CustomRunConfiguration with
a executable name $AAA, the tooltip there tries to expand that
(and complains that $AAA is not an executable).
By inserting a AAA=/bin/ls in the build environment, the tool tip
on the run config exectable path chooser changes appropriately,
same for changing the AAA value.
The connection seems also needed, dropping it destroys that updating.
Change-Id: I28965cbd3ce530a83d98808ca7624a6799cd9800
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For some reason, Q_UNUSED includes already a semicolon, adding one
on the user side creates an additional empty statement.
Change-Id: I9c5e8fac381345a60792cb75e2938fd53958d3b0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... and availableSetups as far as mechanically possible.
Change-Id: Ia1d7babe943eea25da97cef7838187c234378673
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... availableBuilds() and availableSetups().
Goal is to merge them and inline all the local createBuildInfo()
functions.
Change-Id: I9f19093163808b6da6dc83977894420e08a1edd9
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Refactor much of the code from Environment* classes to NameValue* classes
to share it with the preprocessor macro settings.
Change-Id: Ica4ee817aa338230c422b30d91240d266248d226
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
More in line with QFileInfo terminonlogy which appears to be
best-of-breed within Qt.
Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... coming from the line edit. Nobody enters a build directory with
leading or trailing spaces on purpose.
Fixes: QTCREATORBUG-16805
Change-Id: Ic33f126fb9c4c0d008ebeaf00a78c737729be623
Reviewed-by: hjk <hjk@qt.io>
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>
