Qt for some reason doesn't tell the tool chain to require 10.5 when
doing a cocoa build but on x86.

... instead of running a sed script over a lot of files on each
version increment.

Because executable_path and loader_path are just too inflexible for some
stuff. The rpath is supposed to be set to the Qt Creator app's Contents
folder.
Compiling on 10.4 now requires to enter compatibility mode via
QTC_TIGER_COMPAT env variable or TIGER_COMPAT_MODE qmake variable.

Reviewed-by: Thomas Hartmann

this also covers the higher-level includes for libs and plugins

see 576642a7 for details

Christian Kamm convinced me that it should not have any effect.

Reviewed-By: ckamm

Task-Nr: QTCREATORBUG-1646

Reviewed-by: ckamm

This reverts commit 5234c775 and 21065291.

- Enable qmlprojectplugin even if Qml support is disabled.
- But disable its wizards in that case.
- Disable the Qml file wizard if the support is off.

Reviewed-by: Kai Koehne

Requested-by: Friedemann Kleint

... so just disable it for all macs.

includes workaround for breakage with old g++

Only revert stuff that is linked to fast string concat.

This reverts commit e70530c5. It
did break builds on older gcc versions (gcc 4.1.2 64 bit Linux,
gcc 4.0.1 on Mac OS X):

parser/qmljsgrammar_p.h: In static member function ???static int
QmlJSGrammar::nt_action(int, int)???:
parser/qmljsgrammar_p.h:188: error: ???QmlJSGrammar::<anonymous enum>???
is/uses anonymous type
parser/qmljsgrammar_p.h:188: error:   trying to instantiate
???template<class T> struct QConcatenable???
...

Reported-By: Tasuku Suzuki

Instead use qmake IDE_LIBRARY_BASENAME=lib64 to set it to lib64.

This is helpfull for building plugins from outside
the QtCreator source tree.

use the data copying custom compiler approach here, too.
this leaves more work to qmake, which is good.
on the upside, pluginspecs will be installed when they change without
having force a re-link of the plugin itself.
on the downside, installation of a pluginspec will force a re-link of
the plugin. oh, well - you can't have it all (with qmake) ...

IDE_LIBEXEC_PATH is still the bindir, so it's kinda fake. oh, well.

now bin and share are not pegged to linking the executable any more,
but are proper subdirs targets of their own.
unforturnately, qmake is a bit tenacious, so we hack around a bit. :)

more or less in passing by, i removed some superfluous trailing slashes
and added path normalization as well.

Reviewed-by: hjk

Details:  LD_LIBRARY_PATH setting still missing

Details:  Creator on Linux works now in two modes:
          1) out of the build dir (shadow builds to be tested)
          2) make INSTALL_ROOT=/prefix install

Details:  Make install works now, we just have to agree on layout
details and check for mac compatibility.

Also, plugins will carry no version in their filename anymore starting with
this commit. Versioning happens in the creators pluginloader using the pluginspec file.