Change-Id: Ib5423fdd064e4546f848c0b640b0ed0514c26d3a
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>

Introduce priorities for build configuration factories. This way
plugins can register specialized build configuration factories, that
e.g. can provide additional build steps.

A negative priority signifies that a factory is not prepared to
handle a request, the default build configuration factory shipped by
the build system plugin will report a priority of 0. Add 100 to that
for each specialization you add (e.g. a remote linux buildconfiguration
factory would report 100, a specialization of that for mer will
should report 200, etc.).

Change-Id: I141a7a5a79166afdb7657d46eb7e86bd18d3abf6
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Michal Klocek <michal.klocek@digia.com>

Generalize the target setup page and move it into projectexplorer

Move the qmake specific code into a projectimporter class with
a specialization for qmake projects in the qt4projectmanager.

This change depends heavily on the BuildConfigurationFactory cleanups
done earlier and completes that change in such a way that generic
build configuration factories are now in theory possible. The
remaining problem is how to select the best factory of several that
claim to be able to handle a kit and that is left for the next patch.

Change-Id: I47134cb1938c52adebcdc1ddfe8dbf26abbbbeee
Reviewed-by: Daniel Teske <daniel.teske@digia.com>

Refactor the code of the build configuration factories. The idea is to
generalize the code so much that we can allow plugins to install
custom build configuration factories for the platforms they support.

To support this use case the following changes where done here:
 * BuildInfo class was introduced to describe one build configuration that
   can be created by a factory.
 * Factories report a list of BuildInfo to describe what they can produce.
   This fixes the need for factories to implicitly create one buildconfiguration
   and then create another one 'officially' to support debug and release build
   configurations to be set up for projects.
 * Do no longer work around factories to create build configurations.

Change-Id: Ic372e4a9b5c582633b467d130538948472b89d91
Reviewed-by: Daniel Teske <daniel.teske@digia.com>

Use setBuildDirectory() in the different BuildConfigurations instead
of reimplementing that over and over again.

Change-Id: Ic355fdb4624c71667ce470b3e2865c9a8722ef09
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>

Change-Id: Ic6a9ff0359625021ebc061d22db6811814534205
Reviewed-by: Kai Koehne <kai.koehne@digia.com>

They have a identical interface.

Change-Id: Ia626496fbaffedefff6ee20b958cd505085d89f7
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>

Which simply returns a BuildEnvironmentWidget. A long time ago
BuildConfigurations had no environment, nowdays they do. So it makes
sense for all BuildConfigurations to have the BuildEnvironmentWidget.

Change-Id: I824c45df79a0dcd2b624bf67a4730fb5dab098bc
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>

Change-Id: Idf58ebbb02e9cd0ab4ff7e74fbed17250e274693
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>

Which asks each KitInformation for their parser, thus currently creating
a toolchain + qt chain if that is applicable. Remove all code that does
that by hand from various buildsteps/buildconfigurations.

Change-Id: I79a07ffd1dbe9a43bdbc838bc0098071aa412009
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>

Change-Id: Ice592c6de9951ee3b2c4cb52ed0bb3b6770e0825
Reviewed-by: Eike Ziller <eike.ziller@digia.com>

And fix it to the old behaviour while at it.

Change-Id: Ifd786e085c621fb3cd59b98cc665d9e3c7fcce51
Reviewed-by: Tobias Hunger <tobias.hunger@nokia.com>

Fixing an lupdate warning about cyclic dependencies of
autotoolsbuildsettingswidget.h.

Change-Id: I0e1c721df2c5f70ae9de38dd9bc5a34b63622ba7
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>

Introduce Profiles to store sets of values that describe a system/device.

These profiles are held by a target, getting rid of much of the information
stored in the Build-/Run-/DeployConfigurations, greatly simplifying those.

This is a squash of the wip/profile branch which has been on gerrit for a
while, rebased to current master.

Change-Id: I25956c8dd4d1962b2134bfaa8a8076ae3909460f
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>

Use Core::Id for all the project related objects in favor of plain
QStrings.

Change-Id: I790ab40cb29899efdb49c413a77609486f52e683
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>

Change-Id: Ic7862a4a97e60ed016a53f5893e03e3f9ec11e53
Reviewed-by: Patricia Santana Cruz <patriciasc@openismus.com>
Reviewed-by: hjk <qthjk@ovi.com>

Change-Id: Icbc8d105a3ffea2bf705d18e3413f6b3487ccfd3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: hjk <qthjk@ovi.com>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@nokia.com>

Change-Id: If18afb5d4665924e7d9250dccbc60a65e6daa75e
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>

Change-Id: I8b73d583be1ee7183f4074bce49d5390e38631a2

Merge-request: 261
Reviewed-by: dt <qtc-committer@nokia.com>

Fixes a crasd, removes member variable for toolchain

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

Reviewed-by: hjk

Acked-By: dt

Task-Nr: QTCREATORBUG-1130

The API addtition to BuildConfiguration of knowing of the default parser
is rather strange, but a necessary evil for this.

Reviewed-By: Thorbjorn

Task-Nr: QTCREATORBUG-514

The functionality was duplicated between the Qt4 and CMake build
configurations and their configuration widgets. This change moves it
down to BuildConfiguration, in addition also making it available for the
Generic Project.

Also provides an upgrade path for the configuration.

Task-number: QTCREATOR-24
Reviewed-by: dt
Reviewed-by: Tobias Hunger

 * 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

 * Make use of the ProjectConfiguration base class in the
   BuildConfigurations and update the factories accordingly.

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

 * Rework IBuildParser:
    * Remove name() method.
    * Remove enterDirectory and leaveDirectory signals.
    * Allow chaining of parsers.
 * Rename IBuildParser to IOutputParser.
 * Implement GnuMakeParser.
    * Remove entering/leaving directory related code from all other parsers
    * Move filename fixup heuristic based on entering/leaving directory
      massages from gnumake here from AbstractMakeStep.
 * Add outputParser method to ToolChain: This removes the need to map
   toolchains to BuildParser names in the BuildSteps.
 * Enhance AbstractProcessStep to accept a IOutputParser to parse its output.
 * Remove AbstractMakeStep.
 * Set the appropriate Parsers in all classes deriving from AbstractProcessStep
   and append the ToolChain's parser to the parser chain.
 * Remove BuildParserFactories: There is no more need for them.
 * Remove constants used to identify the BuildParsers.
 * Clean up some names:
    * Replace stdOut with stdOutput.
    * Replace addToTaskWindow with addTask and addToOutputWindow with
      addOutput. Do this wherever it is not yet clear that this will end up
      in the Task/Output window.

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.

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