If no 'qmlviewer' executable is found in the PATH, iterate through the
list of configured Qt versions and try to find a qmlviewer there. This
should help users configuring creator such to play with Qml.
Right now the first qmlviewer found in a Qt version is selected. A UI
to let the user select one explicitly was not possible any more (string
freeze).
This requires a dependency from QmlProjectManager to
Qt4ProjectManager.
Reviewed-by: dt
* Add function to check whether the new symbian build system is used
to build a Qt version. This will be used to decide which parsers
to use when building for symbian
This boils down to the same problem as other calls to qmake, if we don't
pass the target mode, qmake will prepend the current platform as target.
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 b1a121c54f.
Accidentally pushed the linux icc parser before it was ready.
Conflicts:
src/plugins/qt4projectmanager/qtversionmanager.cpp
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
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
