Enables users to change which buildsteps get run per buildconfiguration.
Some further tweaks are probably necessary. This is a rather big
change, though it should work. :)

Allows the user to change his mind. :)
Reviewed-by: Friedemann Kleint <qtc-committer@nokia.com>

That is we actually parse the mkspec and evaluate QMAKE_CXX (and a few
other variables) to figure out the correct mkspec. This makes using
custom mkspecs easier and is also cleaner. I also changed mkspec() and
mkspecPath() to behave a little diffrent, essentialy mkspec() will
return only the name (the actual dir name) of the mkspec. That is in
general not sufficient for passing on to qmake. mkspecPath() only
returns the correct path to mkspecs/default.
Hopefully I haven't broken WinCE/Maemo/MinGW.

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

It's easier this way for the unique naming.

Instead use the BuildConfiguration class methods directly.

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

.. and purge unneeded includes.

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.

Now it should finally ask to regenerate in all circumstances. (If you
are using CMake from cvs.)

Made virtual newBuildConfiguration return a bool

Though there's still a bug in that canReadLine() returns false.

Directly in the wizard and save that to the settings. Also give feedback
if a wrong path was entered.

By only providing a qtInstallDir variant

This splits up the edit and active settings. Let people try it and
report usability problems. I'm not 100% convinced of the layout either.

And react to changes to one of them.

Fixes a bug where the cmake plugin wasn't finding make, if the make
commands directory was added to path in the build environment.

If there are multiple files with the same name, then we try harder to
find the correct one. That is for jom and nmake we have a relative path
so we try to find a file which matches the relative path completly.
Instead of just comparing the last part.

Since we can easily do that, just do it. No gurantee that we aren't
going to use rtti in the future.

out of source page.