it's well within expectations that they do not exist at the time of
configuration (especially when shadow building).
additionally, keeping the validation info (macros and environment)
up-to-date would require a notification infrastructure which is just not
worth the effort.
Existing Directory checks for whether the directory exists, which
Directory does not. Also changes all existing PathChoosers from
Directory to ExistingDirectory as that does not change behaviour.
Refactor ToolChains in Qt Creator:
* Allow for several toolchains of the same type
* Be smarter wrt. guessing what kind of output a toolchain
produces. This allows us to eventually handle e.g. embedded
linux setups way better than before.
* Be smarter wrt. guessing what kind of environment a Qt version
needs.
* Improve auto-detection of toolchains a bit
* Decide on which debugger to use based on the kind of output
produced by the compiler.
* Add options page to configure toolchains
* Remove toolchain related options from the Qt version dialog
Reviewed-by: dt
do not inject SOURCEDIR and BUILDDIR into the environment of
build steps and run configurations any more.
instead, all custom executable paths, argument lists and working
directories now support the %{sourceDir} and %{buildDir} macros.
this approach is more elegant and more scalable.
get away from argument stringlists. instead, use native shell command
lines which support quoting/splitting, environment variable expansion
and redirections with well-understood semantics.
Task-number: QTCREATORBUG-542
Task-number: QTCREATORBUG-1564
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.
