'make install' now installs to $(INSTALL_ROOT)$$QTC_PREFIX/...

This is used for giving the contents of the 7zips an additional prefix.
(previously done by doing an additional copying step in bindistHelper).
QTC_PREFIX can also be used to give Qt Creator a different install path
at qmake time, and defaults to /usr/local on Linux.
On Windows and Mac there is no default for QTC_PREFIX.

Usage: qmake -r QTC_PREFIX=/qtcreator-2.6.0 && make &&
INSTALL_ROOT=/tmp/creator-dist make install

Change-Id: Id30781e14bfdde52531800f22b22e39f0459e806
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>

It depends on and mixes in changes made in another change on gerrit
that is not merged, so it breaks the package build.

This reverts commit c29bf6f6.

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

Reason: $INSTALL_ROOT is only meant to be used by packagers
to temporarily put the contents into a different location,
which is needed for fakeroot packaging.

QTC_PREFIX is not a qmake variable, and defaults to
/usr/local. On Windows the default prefix is "QtCreator",
since "make install" is expected to be used in
a packaging context only where either INSTALL_ROOT
should be used or QTC_PREFIX should be set to the
absolute destination path where e.g. an installer
generator will pick it up.

Change-Id: Ifa4950340e58e34726c53f5417adcc7b50828ce1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>

yet another hack

Change-Id: Ic041e8bdfb7331d6934620c8fbb91435f3495ba7
Reviewed-on: http://codereview.qt-project.org/4790


Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Daniel Molkentin <daniel.molkentin@nokia.com>

we need to override RUNPATHs from possible plugins.

due to d7d23226, this should not re-introduce QTCREATORBUG-1646.

unlike in the previous incarnation, we don't replace the binary with the
script, but give the script an extension. this is nicer for packagers
and less confusing in creator's own run configurations. the .desktop
files created by our installers need to be adjusted for that.

Task-number: QTCREATORBUG-5565
Change-Id: Icd2fa55456754a05257376b8288e8bdf423c62db
Reviewed-on: http://codereview.qt.nokia.com/3180


Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Daniel Molkentin <daniel.molkentin@nokia.com>
Reviewed-by: Christian Kamm <christian.d.kamm@nokia.com>

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

Reviewed-By: ckamm

Task-Nr: QTCREATORBUG-1646

Task-Nr: QTCREATOR-116

./bin/qtcreator: 3: Syntax error: "(" unexpected

First, there's no $( ) for subshells. You have to use backticks.

Second problem, "VAR=value exec command" doesn't work. Split into
variable setting, exporting and then exec'ing the program.

Third, Solaris doesn't come with readlink, so parse the output of ls -l.

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.

Thanks to "catanzag" on the labs blog.

Bug reported and fix suggested by catanzag on Qt Labs blog. Thanks!

Reviewed By: Thorbjorn Lindeijer <thorbjorn.lindeijer@nokia.com>

RevBy: hjk

Details:  LD_LIBRARY_PATH setting still missing

This makes both source and log files more readable and also prevents
gdb from applying extra quoting of its own.

Simple solution after all. This idea got initially dropped early in the
process because it does not handle binary data and using x/x was
way to slow. But since we use only printable characters now thanks
to base64 encoding etc using 'p' becomes feasible again and simplifies
the process vastly as no additional communication channel is needed anymore.

Details: Moving files so that the local layout corresponds to the layout pushed by make install.
Adjust Make target, modify the resource path of the loader to find the resources in the
right place. All pathes are still looked up relative to binaryPath(), libs are found via
relative rpath.

to the "user space" (gdbmacros.cpp)

qualification like 'const char *'