GitLab

Reviewed-by: Alessandro Portale

Try to find matching version for mkspec.
Rubber-stamped-by: Joerg Bornemann <qtc-committer@nokia.com>

Reviewed-by: dt

Handle qmake with or without trailing .exe on windows. Looks like the
extension got lost recently in the generated Makefiles.

Reviewed-by: dt

Reviewed-by: dt

Reviewed-By: hunger

Reviewed-by: dt

This patch marks up invalid Qt versions as Desktop.

Make sure we add a the always existing invalid Qt version in the path
available in the targetselectionpage if no valid Qt versions could be found.

This way a project can be set up and loaded without a valid Qt version set up.
Trying to build this will fail of course. This is basically how we handled
this situation before we had targets, too.

Task-number: QTCREATORBUG-1066
Reviewed-by: dt

This reverts commit b1a121c5.

Accidentally pushed the linux icc parser before it was ready.

Conflicts:

	src/plugins/qt4projectmanager/qtversionmanager.cpp

That means wrong target (though argueable we don't have a correct one
yet, but working defines and includes.

Fixes creating these pages unnecessarily when the Welcome plugin is not
loaded, as well as "leaking" them in that case.

Reviewed-by: con

We used to ignore if someone had set a additional for his qmake, with
qmake -set QMAKEFEATURES. The fix is a simple oneliner from Filip
Piechocki. See qt-creator merge request 130.

Task-Nr: QTCREATORBUG-805

Some mkspecs do have a QMAKESPEC_ORIGINAL and yet that directory doesn't
exist. In that case ignore it.

Task-Nr: QTCREATORBUG-586

Only if we need the information.

This is a big change touching almost all of our .pro file parsing.
With this patch we only evaluate once exact for all needs and once
greedy for the filelist. That is the qt runconfigurations don't have own
evaluaters but reuse the project wide exact evaluation.

We reevaluate if the user changes the build directory, the qmake
buildconfiguration or the qmake arguments. That is if you open src.pro
(or projects.pro) of qt with a shadow build you still don't get all the
files, but after correcting the build directory, we reevaluate the .pro
files and find all files. So for a suitable definition of fixed, that
bug is now fixed.

We now get the exact defines of all .pro files instead of all defines for all
buildconfigurations. We still don't distinguish in which
.pro file a DEFINE is set. So the code model now knows about all the
defines set for the given configuration but not for which files it is
actually set. Also that includes all DEFINES set in .qmake.cache or the
mkspecs. This means all defines from .pro files should now work.

The intial loading is still synchronous. I haven't looked into it to
deeply, but it seems possible to make it also async.There are probably a
few issues which need to be solved fist.

Also due to the asynchronous nature of the code, the executable is
updated a few seconds after actually changing the build configuration

Reviewed-by: kh1

 * kh1 says there is no such thing as there is no technical
   destinction between Maemo devices and the Maemo emulator.

Reviewed-by: kh1

Since we use addAutoReleasedObject we would rather unclean call the
class destructor.

 * Fixes update of Qt version name whne renaming a Qt version.

 * We get a bogus Qt imported otherwise

- Autodetect SDK by environment variable EPOCROOT and qt directory
below.
- Environment::appendOrSet/prependOrSet: Avoid duplicate entries
- Rename toolchain enumeration value
- Adapt S60ToolChainMixin to new GnuPoc setup, provide routines for
  all required variables.
- RVCTToolChain: Make RVCT detection smarter (Check for RVCT<v1><v2>BIN
  variable). Set all required variables in case of RVCTToolChain/GnuPoc
- QtVersionManager: Detect toolchain and Qt version properly, make S60
  device run config accept toolchain.
- Modify S60DeviceRunControl to execute 'make sis'
- Modify S60Devices::detectQt...() to check for Qt installed into SDK
  first and symlink as fallback.