There's a UI in qml/customexec/cmake/qmake run configs for choosing the
debugger languages (C++ and QML). The default for all except .qmlproject
is only C++, so default debugging behavior is the same. However, if the
user wants to do simultaneous debugging with two languages, or only
debug QML, they can select the languages from Run Settings and it will
be remembered.
Reviewed-by: hunger
* Enable support for this in all ProjectConfiguration items
(Targets, projects, BCs, DCs, RCs, etc.). This is nicer
than having custom code in individual configuraiton items.
Reviewed-by: dt
Using more *::Constants::ICON_* where it makes sense and
wrapping the file names into QLatin1String where they were
missing.
The increased usage of the ICON constants needed a few more
cross plugin includes of *constants.h, here and there.
I think that it is OK, since the dependencies were alredy there
icon resource wise.
Just disable them, but preserve them. This is different from qmake, but
for qmake we do have different assumptions what a buildconfiguration is.
Task-Nr: QTCREATORBUG-1591
* Ease cross device development by introducing 'targets' which
group build- and runsettings that are valid for this one target
Most of the kudos for the code review go to dt. Con, thorbjorn,
ckandler and others did also review parts of this patch.
Reviewed-by: dt
* Use id() for methods returning a string used to represent
some type of object.
* Use displayName() for strings that are meant to be user
visible.
* Quieten some warnings while touching the files anyway.
* Move Factories to their products in the plugins where that
was not done before.
Reviewed-by: dt
Otherwise we need to parse the cbp file, which happens only if the
buildconfiguration gets active. Also try to decouple a few internals a
little bit by using signals. The CMakeProject still handles a few things
directly instead of via signals, more to come eventually.
and ApplicationRunConfiguration to LocalApplicationRunConfiguration,
preparing remote debugging. Change the interface canRun() to be const,
run() to create() (since it does not run anything), use references
to the QSharedPointer<Foo>. Introduce d-Pointer and remove
unneeded headers from ProjectExplorerPlugin and add missing includes
everywhere.
Adds a little bit of code duplication, don't currently know how to best
avoid it, so I'll leave that for now as is. To be tested once Andre
pushes his stuff.
We used to build a helper library as part of the project. First with the
qmake -after SOURCES= stuff and after until now with the
gdbmacrosbuildstep. Now, the all new and fancy integretation directtly
into the qt version dialog. You build the debugger library once for
each qt version and then it's there ready to be loaded into each
project build against that qt version. Saves a lot of time.
And makes it possible to also load that library into while debuggign a
cmake project. (Need to hook that up now.)
Unfourtanetly this breaks the custom dumpers if you use a custom run
executable.
