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

they are initialized from the build configuration upon construction

Acked-By: dt

Must be compiled during runtime - otherwise, the app may not work
with Qt that is compiled with another compiler.

Reviewed-by: hjk

Ups were wrong in the last commit

Ups were wrong

Reviewed-by: dt

Relative to the project's directory.

Reviewed-by: dt

It was badly positioned esp. in OS X and Windows.

Reviewed-by: dt

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

Reviewed-by: ossi

Renamed RunConfiguration::configurationWidget to
createConfigurationWidget.

Reviewed-by: dt

 * 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

This is in preparation of the addition of "targets" in the
sense of "platforms to develop for" into the codebase.

Reviewed-by: dt

Reviewed-by: dt

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

Task-Nr: QTCREATORBUG-277

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.

Note: I didn't fix all the connects and there are a few missing things.
This compiles, more work is coming.

The pointers can be used to distinguish BuildConfigurations

Also move Designer::Internal::FormWindowEditor ->
Designer::FormWindowEditor.

Builds, but I'm pretty sure it doesn't *work* :)

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.