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>
... over setting command and args individually.
Change-Id: Iec7c8d3a0b05fb8fa0639f7ddbe7ccdc7387d2a2
Reviewed-by: Christian Kandeler <christian.kandeler@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>
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>
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>
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>
Fix crashes due to activeProjectConfigurationChanged signal sending
a nullptr.
Uses the same fix as QTCREATORBUG-18865, but in more places:-)
Task-number: QTCREATORBUG-18866
Change-Id: Ic71af5ed26b2a44339f0c687f3f46bfdf62c2489
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>
BREAKS BACKWARD COMPATIBILITY OF TOOLCHAIN SETTINGS!
* Convert old ToolChainKitInformation to new version
* Store several toolchains in one kit (one per language)
Change-Id: Ia59a2ad067c57971ec34ce9b2e43758344443755
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
This removes 900 lines of duplicated code, some duplicated checks at
runtime and some (minor) quadratic behavior when gathering display names.
canClone(), canRestore() and canCreate() and restore() use the same
pattern. Handle that on the core side once. Leave retore() virtual to let
the ios code unmodified (which is likely not needed, later...). Introduce
'Unclonable' and 'Uncreatable' flags to keep Android package installation
and WinRT deployment (non-)functionality unchanged.
Change-Id: I0325479aff818a4038b2f241ca733b8d8cd66f2f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This information can be used to get information from earlier steps,
which e.g. queried for android devices to deploy to.
Change-Id: Iefe1c9443915cb6211f86f98ff7aaf3cb75145ba
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
We define a Profile build to be a Release build with separate debug
info. You can thus change a given build from Release to Profile of vice
versa by toggling the separate debug info checkbox. The messaging for
future user interaction about Profile builds has to take this into
account.
Task-number: QTCREATORBUG-14009
Change-Id: I62a5b13993b20bf36329b1eefa8b1b6096f31644
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Mostly done using the following ruby script:
Dir.glob('**/*.cpp').each { |file|
next if file =~ %r{src/shared/qbs|/qmljs/}
s = File.read(file)
s.scan(/^using namespace (.*);$/) {
ns = $1
t = s.gsub(/^(.*)\b#{ns}::((?!Const)[A-Z])/) { |m|
before = $1
char = $2
if before =~ /"|\/\/|\\|using|SIGNAL|SLOT|Q_/
m
else
before + char
end
}
if t != s
puts file
File.open(file, 'w').write(t)
end
}
}
Change-Id: I8ef73f4861069dcd7edf5e73b397d60609d4b476
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@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>
Everybody used to do their own thing...
Also unify the "Configuration is faulty" message we write into the
Application output window.
Change-Id: I0e5c4ec68155d66aa1d0ea53134b98917869e5c6
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
The lldb debugger sometime returns misleading debug information
unless a dsym has been created.
This creates a build step to do it.
Task-number: QTCREATORBUG-11580
Change-Id: I7acf2e539cf189d0237e1d502fab2837f17aa489
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
first work in progress support for ios
* separate iosTool using xml communication used for device info and run
* iossim tool to handle the simulator
* debug prepared but not working
* separate gcc toolchain detection fix for simulator
1) add a QT built for ios
2) open a project, for example qtbase/examples/widgets/animation/animatedtiles/animatedtiles.pro
3) build/run...
Change-Id: I7e01604e416338cbe4692dfb34f5d3f31312702d
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
