First step, move {DesktopQt,Qbs,CMake}RunConfiguration{,Factory}
into the same new files.
This only moves down to QtSupport, not ProjectExplorer, as there
are in all three cases direct dependencies on QtSupport. Long term
I would expect them to move further down.
Change-Id: Ib16b19df7f3f642ed7f7db89a1f6904601d976ba
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... by a Project::buildConfigurationChanged. That's the only case
used, and saves filtering on the receiver side. Also, the passed
bc is (in non-null) the active one, so isActive checks are not
necessary.
The null case seems to be only possible to trigger when removing
the currently active build configuration manually i.e. happens rarely,
so having it trigger an unneeded final display update on the dying
build config is tolerable, so drop the null check in such cases
to achieve a more uniform pattern.
Change-Id: I46f72e9e277767214dbd6920dd86b026a7084f46
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Updating on changes to other build config seem excessive, as the
updated details only depend the owning build config.
Change-Id: Iba86f2b56033ac55381d452dd2a435e5dda72674
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Targets are different from {Run,Build,Deployment}Configurations,
both regarding the level in the ProjectExplorer hierarchy, and
also by the set of supported operations (e.g. aspects).
Change-Id: Ia8490e2280a9ecc518395c5e48ce2fd5d6d58fd2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Select a better fallback target when a buildstep's target is no longer defined.
This change was cherry-picked from master branch:
9519f125e9
Change-Id: I7ef27361793125258cd2a73448d91d2561db5901
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Update the target list in the build step list widget for CMakeBuildSteps,
even when "current executable" meta-target is selected.
This change was cherry-picked from master branch:
ce7407dc03
Change-Id: Ifc1d8dc67894202eb38fe6088552797b198c7463
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Add a helper method to find the default build target for a CMakeBuildStep
based on the BuildStepList the step is part of. Use all/install/clean
targets as appropriate.
This change has been cherry-picked from master branch:
8b9821440d
Change-Id: Idc0c5fae7dfd255039b87ace77c02688cdd76e8f
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This patch is not applicable to the master-branch: The buildkeys
for cmake targets have changed there.
Task-number: QTCREATORBUG-22634
Change-Id: I1c8abc42792a004bdadc893129c96e1b7ed428f6
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The CMakeParser used to set relative paths in the Tasks it creates.
Since is problematic: Task tries to match that relative file name to
one of the files that exist in the session.
At the time cmake runs only the top-level CMakeLists.txt file is known,
so this logic will map all the relative file paths to that file.
Make sure to write absolute file paths into tasks so that this mapping
is not attempted.
Change-Id: I4ab72df21f18d2eff27ca9a502d605e00df2ad85
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Select a better fallback target when a buildstep's target is no longer defined.
Change-Id: I7ef27361793125258cd2a73448d91d2561db5901
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Update the target list in the build step list widget for CMakeBuildSteps,
even when "current executable" meta-target is selected.
Change-Id: Ifc1d8dc67894202eb38fe6088552797b198c7463
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Add a helper method to find the default build target for a CMakeBuildStep
based on the BuildStepList the step is part of. Use all/install/clean
targets as appropriate.
Change-Id: Idc0c5fae7dfd255039b87ace77c02688cdd76e8f
Reviewed-by: Eike Ziller <eike.ziller@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>
For the command and the working directory.
Change-Id: Ia69dc7100aeb57bb6e1b35f4dd4f3cf3763d8cda
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>
Originally, the build manager used to run all build steps in a dedicated
thread. Communication between the step and the manager happened via a
QFutureInterface that was passed into the step's run() function.
Later, new steps were added that operated asynchronously, so the build
manager had to differentiate between the different kinds of steps for
starting and stopping.
These days, almost all build and deploy steps work asynchronously, which
made the QFuture-based interface look increasingly odd.
With this patch, all build steps are expected to work asynchronously, so
the build manager no longer needs to differentiate. Steps are started
and requested to stop via the run() and cancel() functions,
respectively, and emit the finished() signal when they are done. Build
step implementors no longer have to deal with a QFutureInterface. For
steps whose implementation is inherently synchronous, the BuildStep base
class offers a runInThread() function.
Change-Id: If905c68b234c5a669f6e19f43142eaa57d594803
Reviewed-by: hjk <hjk@qt.io>
When first loading a CMake project, if parsing fails all targets get reset
to the "all" target. Most commonly users will notice this when the "clean"
target gets reset to "all", and can often go unnoticed for a while. This
can become especially annoying when custom target configurations are used.
With this change the previous targets will be preserved upon failure.
Fixes: QTCREATORBUG-21617
Change-Id: I52a3a2c472c7b8d98bc016b1e55a202147fc091c
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The extra parameter was always computed but used only in one place,
and that use got removed lately.
Change-Id: Ie10c0107ca70ee97ce03f83294992aab8d1a3ffe
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Default to false, remove all no-op reimplementations.
And rename the getter to isImmutable according to the rules.
Change-Id: I8cce79d88fb59badfa1cffcf30a46f7ff3b09e8b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
From a virtual function to a normal one backed by a real data member.
That's essentially what several re-implementations did, the other
ones used a fixed value instead.
Change-Id: I61e45f1d4f7f0f80fe2eb1f2729785f37e7bb803
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Use BuildStep::displayName() as default.
This probably could be the only possibility, but currently there
are some discrepancies that are kept in this patch to make
the patch mechanical.
Change-Id: I2a1e5c2ff37ad95e25309eb16e07099e42191f60
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The extra m_step member is not worth the abstraction, especially
since almost all non-SimpleBuildStepWidget have something similar,
too. Also, as several derived classes needed to correct
SimpleBuildStepWidget's setShowWidget(false).
Change-Id: I6e80d8c84c363b90dc27c70abd7fa6cefa1ed91e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
De-QObject-ify class, tr contexts are now the product's
context, which was the case in some BuildStepFactories already,
and is current state in {Run,DeployConfiguration}Factory.
One spurious object name removed.
De-virtualize canHandle(), it was never overloaded and is not
intended to be overloaded anymore.
Remove unused clone() function.
Change-Id: Iff7fba5f707505f868f94458084a18650535fa23
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
If a step is part of a build configuration, that is used, but many steps
can be used as part of a deploy configuration.
In that case the active build configuration of the step's target must be
used, and that logic was duplicated many times.
Instead, let BuildStep::buildConfiguration take care of that logic. For
steps that are not offered for deploy configurations there is no
semantic difference, and for the others this removes code duplication.
Change-Id: I02f3bb50226590092cedcec02fce6fde9c7c6e63
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The previously per-Project/RunConfiguration changing meanings of
BuildTargetInfo::buildTarget have by now been split
into separate values in BuildTargetInfo:
- buildKey a handle to one item in Target::applicationTargetList
- displayName a user-visible string in the run settings page
The buildKey was tweaked to coincide with the previous 'extraId',
i.e. the non-RunConfiguration-type part of the project configuration
id that (still) use id mangling.
This allows replacing the cases of locally stored seven different
versions of buildKey(-ish) data by one RunConfiguration::m_buildKey,
and do all remaining extraId handling in RC::{from,to}Map only,
i.e. remove the base ProjectConfiguration::extraId() virtual and
remove the "re-try fromMap with mangled id" hack entirely.
The id mangling is still used to temporarily maintain .user file
compatibility in some cases for now, but should be replaced by
storing the build key and the RunConfiguration type soon. Qbs
already changes in here to only use the uniqueProductName as
buildKey, without the previously added display name which is
stored as part of the ProjectConfiguration already.
It turns out that RunConfiguration::buildSystemTarget was intended
and used to retrieve an item from the Target::applicationTargetList
for some configurations, coinciding with what buildKey does always.
So use that insteand and drop RunConfiguration::buildSystemTarget.
There is clearly is further consolidation potential left.
handling of (default)displayNames is still a per-runconfiguration
mess and there is further consolidation potential left.
Change-Id: I448ed30f1b562fb91b970e328a42fa5f6fb2e43e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
"cmake --build ." is useful to build, clean and deploy, so offer it
everywhere.
This fixes soft asserts as a side effect when loading cmake projects with
existing "cmake --build . --target=clean" in their clean steps.
Change-Id: I39e5866f6012b9ea1153da324e4abd1cd25fea92
Reviewed-by: hjk <hjk@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>
This builds on top of 08677c0b01 and
fixes one more code path to go through a common entry/exit point.
Change-Id: I1d00fa9242f247028e5d3b0ef3b5fe1d3f4cb03d
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@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>
Warn when attempting to do an out-of-source build while an in-source build
is configured. This seems to confuse cmake.
Task-number: QTCREATORBUG-18381
Change-Id: I1abd3be4129ba5af6439dcd60d16d429b93c0382
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Its a QObject, no need for QCoreApplication::translate here.
Change-Id: I3375a70fe60b66e13de6b9a99c35c85f82b9151e
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
If an error occurs while persisting or updating the cmake state, the
build might continue for a while in the background.
CMakeBuildStep does not disconnect the Error/Run-Trigger when an
error is signaled by the CMakeBuildConfiguration. Instead it reports the
build as finished (with error). The BuildManager then disconnects the
output and runs the next item in the build queue (if any). However the
cmake step might still be alive and emits the dataAvailable signal which
then triggers the build process.
Task-number: QTCREATORBUG-18382
Change-Id: I956133fe8c6f7de58b9f842b231c70d24778b1e0
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
